--- Day changed Mon Aug 27 2018 00:06 -!- bitconner [~conner@c-67-188-149-218.hsd1.ca.comcast.net] has joined #lightning-dev 00:17 -!- enemabandit [~enemaband@16.77.54.77.rev.vodafone.pt] has joined #lightning-dev 00:21 -!- enemabandit [~enemaband@16.77.54.77.rev.vodafone.pt] has quit [Ping timeout: 244 seconds] 00:30 -!- abcbc [~Traino@2a07:5741:0:135b::1] has joined #lightning-dev 00:34 -!- Traino [~Traino@2a07:5741:0:135b::1] has quit [Ping timeout: 264 seconds] 00:40 -!- booki [~booki@host-89-229-202-113.dynamic.mm.pl] has joined #lightning-dev 00:40 -!- booki [~booki@host-89-229-202-113.dynamic.mm.pl] has left #lightning-dev [] 00:54 -!- deafboy [quasselcor@cicolina.org] has quit [Remote host closed the connection] 00:59 -!- bitonic-cjp [~bitonic-c@2001:981:9573:1:9475:e1ff:fe44:6a7d] has joined #lightning-dev 01:00 -!- deafboy [quasselcor@cicolina.org] has joined #lightning-dev 01:03 -!- Traino [~Traino@2a07:5741:0:135b::1] has joined #lightning-dev 01:06 -!- abcbc [~Traino@2a07:5741:0:135b::1] has quit [Ping timeout: 252 seconds] 01:17 -!- RubenSomsen [uid301948@gateway/web/irccloud.com/x-yhprawovioqnueze] has joined #lightning-dev 01:24 -!- abcbc [~Traino@2a07:5741:0:135b::1] has joined #lightning-dev 01:27 -!- Traino [~Traino@2a07:5741:0:135b::1] has quit [Ping timeout: 264 seconds] 01:40 -!- _bitonic-cjp [~bitonic-c@89.200.0.111] has joined #lightning-dev 01:40 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #lightning-dev 01:40 -!- _bitonic-cjp [~bitonic-c@89.200.0.111] has quit [Read error: Connection reset by peer] 01:41 -!- bitonic-cjp [~bitonic-c@2001:981:9573:1:9475:e1ff:fe44:6a7d] has quit [Remote host closed the connection] 01:41 -!- _bitonic-cjp [~bitonic-c@2001:981:9573:1:4c5:9aff:fe7c:24ab] has joined #lightning-dev 01:41 -!- _bitonic-cjp [~bitonic-c@2001:981:9573:1:4c5:9aff:fe7c:24ab] has quit [Client Quit] 01:42 -!- bitonic-cjp [~bitonic-c@2001:981:9573:1:4c5:9aff:fe7c:24ab] has joined #lightning-dev 01:52 -!- deusexbeer [~deusexbee@095-129-175-228-dynamic-pool-adsl.wbt.ru] has quit [Ping timeout: 252 seconds] 01:53 -!- deusexbeer [~deusexbee@093-092-177-058-dynamic-pool-adsl.wbt.ru] has joined #lightning-dev 01:55 -!- abcbc [~Traino@2a07:5741:0:135b::1] has quit [Ping timeout: 264 seconds] 02:09 -!- tombusby [~tombusby@gateway/tor-sasl/tombusby] has quit [Remote host closed the connection] 02:10 -!- tombusby [~tombusby@gateway/tor-sasl/tombusby] has joined #lightning-dev 02:11 -!- melvster [~melvin@ip-86-49-18-198.net.upcbroadband.cz] has quit [Ping timeout: 244 seconds] 02:17 -!- Traino [~Traino@2a07:5741:0:135b::1] has joined #lightning-dev 02:26 -!- melvster [~melvin@ip-86-49-18-198.net.upcbroadband.cz] has joined #lightning-dev 02:40 -!- riclas [riclas@148.63.37.111] has joined #lightning-dev 02:46 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Remote host closed the connection] 02:47 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #lightning-dev 02:53 -!- deusexbeer [~deusexbee@093-092-177-058-dynamic-pool-adsl.wbt.ru] has quit [Ping timeout: 244 seconds] 02:53 -!- deusexbeer [~deusexbee@093-092-178-150-dynamic-pool-adsl.wbt.ru] has joined #lightning-dev 02:55 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev 02:55 -!- bitonic-cjp [~bitonic-c@2001:981:9573:1:4c5:9aff:fe7c:24ab] has quit [Remote host closed the connection] 02:55 -!- _bitonic-cjp [~bitonic-c@2001:981:9573:1:4c5:9aff:fe7c:24ab] has joined #lightning-dev 03:23 -!- _bitonic-cjp [~bitonic-c@2001:981:9573:1:4c5:9aff:fe7c:24ab] has quit [Remote host closed the connection] 03:23 -!- _bitonic-cjp [~bitonic-c@2001:981:9573:1:4c5:9aff:fe7c:24ab] has joined #lightning-dev 03:42 -!- bitconner [~conner@c-67-188-149-218.hsd1.ca.comcast.net] has quit [Ping timeout: 272 seconds] 03:59 -!- bitconner [~conner@c-67-188-149-218.hsd1.ca.comcast.net] has joined #lightning-dev 04:03 -!- bitconner [~conner@c-67-188-149-218.hsd1.ca.comcast.net] has quit [Ping timeout: 252 seconds] 04:23 -!- kallisteiros [scientist@gateway/vpn/privateinternetaccess/kallisteiros] has joined #lightning-dev 04:53 -!- tombusby [~tombusby@gateway/tor-sasl/tombusby] has quit [Ping timeout: 250 seconds] 05:02 -!- dougsland [~douglas@c-73-234-93-65.hsd1.nh.comcast.net] has joined #lightning-dev 05:05 -!- Traino [~Traino@2a07:5741:0:135b::1] has quit [Remote host closed the connection] 05:05 -!- Traino [~Traino@2a07:5741:0:135b::1] has joined #lightning-dev 05:07 -!- dougsland [~douglas@c-73-234-93-65.hsd1.nh.comcast.net] has quit [Ping timeout: 268 seconds] 05:12 -!- tombusby [~tombusby@gateway/tor-sasl/tombusby] has joined #lightning-dev 05:13 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 252 seconds] 05:15 -!- tombusby_ [~tombusby@gateway/tor-sasl/tombusby] has joined #lightning-dev 05:16 -!- tombusby [~tombusby@gateway/tor-sasl/tombusby] has quit [Remote host closed the connection] 05:17 -!- Traino [~Traino@2a07:5741:0:135b::1] has quit [Remote host closed the connection] 05:18 -!- Traino [~Traino@2a07:5741:0:135b::1] has joined #lightning-dev 05:23 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev 05:39 -!- Traino [~Traino@2a07:5741:0:135b::1] has quit [Remote host closed the connection] 05:40 -!- Traino [~Traino@2a07:5741:0:135b::1] has joined #lightning-dev 05:44 -!- itaseski [~itaseski@213.135.176.114] has joined #lightning-dev 05:46 -!- Traino [~Traino@2a07:5741:0:135b::1] has quit [Remote host closed the connection] 05:46 -!- Traino [~Traino@2a07:5741:0:135b::1] has joined #lightning-dev 05:46 -!- ebx [~ebx@unaffiliated/ebex] has joined #lightning-dev 06:00 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #lightning-dev 06:08 -!- kallisteiros [scientist@gateway/vpn/privateinternetaccess/kallisteiros] has quit [Ping timeout: 268 seconds] 06:20 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Remote host closed the connection] 06:27 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #lightning-dev 06:31 -!- GTHaxor [~GTHaxor@pool-70-106-244-199.clppva.fios.verizon.net] has left #lightning-dev [] 06:34 -!- tombusby_ [~tombusby@gateway/tor-sasl/tombusby] has quit [Ping timeout: 250 seconds] 06:35 -!- Traino [~Traino@2a07:5741:0:135b::1] has quit [Remote host closed the connection] 06:36 -!- Traino [~Traino@2a07:5741:0:135b::1] has joined #lightning-dev 06:41 -!- tombusby [~tombusby@gateway/tor-sasl/tombusby] has joined #lightning-dev 06:42 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Ping timeout: 250 seconds] 06:42 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Ping timeout: 250 seconds] 06:44 -!- marcinja [~marcin@static-100-38-11-146.nycmny.fios.verizon.net] has joined #lightning-dev 06:45 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #lightning-dev 06:47 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #lightning-dev 07:06 -!- Traino [~Traino@2a07:5741:0:135b::1] has quit [Remote host closed the connection] 07:06 -!- rdymac [uid31665@gateway/web/irccloud.com/x-hpabhzzowgwnylvq] has joined #lightning-dev 07:06 -!- Traino [~Traino@2a07:5741:0:135b::1] has joined #lightning-dev 07:10 -!- kallisteiros [scientist@gateway/vpn/privateinternetaccess/kallisteiros] has joined #lightning-dev 07:13 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Ping timeout: 250 seconds] 07:22 -!- michaelsdunn1 [~michaelsd@unaffiliated/michaelsdunn1] has joined #lightning-dev 07:23 -!- dougsland [~douglas@c-73-234-93-65.hsd1.nh.comcast.net] has joined #lightning-dev 07:25 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #lightning-dev 07:31 -!- pokazef [~mikael@2001:41d0:a:4c49::aca:7928] has quit [Ping timeout: 264 seconds] 07:32 -!- Rootsudo [~textual@180.190.116.254] has joined #lightning-dev 07:32 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Quit: = ""] 07:32 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has quit [Read error: Connection reset by peer] 07:33 -!- cryptapus [~cryptapus@jupiter.osmus.org] has joined #lightning-dev 07:33 -!- cryptapus [~cryptapus@jupiter.osmus.org] has quit [Changing host] 07:33 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has joined #lightning-dev 07:33 -!- pokazef [~mikael@2001:41d0:a:4c49::aca:7928] has joined #lightning-dev 08:08 -!- Kaizen_ [~kaizen_@38.98.37.138] has joined #lightning-dev 08:17 -!- _bitonic-cjp [~bitonic-c@2001:981:9573:1:4c5:9aff:fe7c:24ab] has quit [Quit: Leaving] 08:22 -!- Kaizen_ [~kaizen_@38.98.37.138] has quit [Remote host closed the connection] 08:24 -!- Kaizen_ [~kaizen_@38.98.37.138] has joined #lightning-dev 08:25 -!- Kaizen_ [~kaizen_@38.98.37.138] has quit [Remote host closed the connection] 08:25 -!- Kaizen_ [~kaizen_@38.98.37.138] has joined #lightning-dev 08:31 -!- Kaizen_ [~kaizen_@38.98.37.138] has quit [Ping timeout: 276 seconds] 08:46 -!- Kaizen_ [~kaizen_@38.98.37.138] has joined #lightning-dev 08:54 -!- JackH_ [~laptop@host86-182-8-23.range86-182.btcentralplus.com] has quit [Ping timeout: 268 seconds] 09:02 -!- Kaizen_ [~kaizen_@38.98.37.138] has quit [Read error: Connection reset by peer] 09:02 -!- Kaizen_ [~kaizen_@38.98.37.138] has joined #lightning-dev 09:06 -!- xchuck00 [~xchuck00@unaffiliated/xchuck00] has quit [] 09:08 -!- melvster [~melvin@ip-86-49-18-198.net.upcbroadband.cz] has quit [Ping timeout: 268 seconds] 09:21 -!- Tralfaz [~none@64.120.44.139] has joined #lightning-dev 09:21 -!- Kaizen_ [~kaizen_@38.98.37.138] has quit [Remote host closed the connection] 09:26 -!- Amperture [~amp@24.136.5.183] has quit [Remote host closed the connection] 09:26 -!- Kaizen_ [~kaizen_@38.98.37.138] has joined #lightning-dev 09:30 -!- Kaizen_ [~kaizen_@38.98.37.138] has quit [Ping timeout: 272 seconds] 09:33 -!- Kaizen_ [~kaizen_@38.98.37.138] has joined #lightning-dev 09:33 -!- tombusby [~tombusby@gateway/tor-sasl/tombusby] has quit [Ping timeout: 250 seconds] 09:33 -!- Amperture [~amp@24.136.5.183] has joined #lightning-dev 09:33 -!- Amperture [~amp@24.136.5.183] has quit [Remote host closed the connection] 09:34 -!- Amperture [~amp@24.136.5.183] has joined #lightning-dev 09:39 -!- HFRadical [~none@91.214.169.69] has joined #lightning-dev 09:40 -!- melvster [~melvin@ip-86-49-18-198.net.upcbroadband.cz] has joined #lightning-dev 09:41 -!- Kaizen_ [~kaizen_@38.98.37.138] has quit [Remote host closed the connection] 09:42 -!- Tralfaz [~none@64.120.44.139] has quit [Ping timeout: 264 seconds] 09:46 -!- tombusby [~tombusby@gateway/tor-sasl/tombusby] has joined #lightning-dev 10:03 -!- Traino [~Traino@2a07:5741:0:135b::1] has quit [Quit: Leaving] 10:22 -!- Rootsudo [~textual@180.190.116.254] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 10:25 -!- Rootsudo [~textual@180.190.116.254] has joined #lightning-dev 10:26 -!- kallisteiros [scientist@gateway/vpn/privateinternetaccess/kallisteiros] has quit [Ping timeout: 272 seconds] 10:27 -!- kallisteiros [scientist@gateway/vpn/privateinternetaccess/kallisteiros] has joined #lightning-dev 10:52 -!- Kaizen_ [~kaizen_@38.98.37.138] has joined #lightning-dev 10:57 -!- Kaizen_ [~kaizen_@38.98.37.138] has quit [Remote host closed the connection] 11:08 -!- tombusby [~tombusby@gateway/tor-sasl/tombusby] has quit [Ping timeout: 250 seconds] 11:09 < BlueMatt> wait, how are things expected to relay the new bits in channel_update? 11:10 < BlueMatt> seems like its now required that channel_updates be kept around in originally-encoded form (ie up to 64KB per channel_update) and you cannot prune them down to their real size 11:10 < BlueMatt> cause the signature covers the feature bits which you then MUST relay the htlc_maximum_msat 11:11 < BlueMatt> also its definitely not backwards-compatible because any impl that wasnt storing a full up-to-64KB-encoded message for each channel_update now relays bogus channel_updates 11:13 < BlueMatt> rusty: it was your proposal ^ 11:16 < BlueMatt> or, at least, given the message forwarding requirements means that such channel updates will never propagate until network has materially upgraded 11:19 < BlueMatt> is the intent to stagger upgrades (which should probably be specified?) or should a node announce two versions of each channel_update - one without the capacity and one with with a timestamp one higher (which should be specified?) 11:28 < BlueMatt> also, would anyone object to changing BOLT 7 to add an announcement_signatures SHOULD that indicates that you SHOULD wait to send an announcement_signatures until the both sides have funding_lock'ed? that way you never need to store the remote end's announcement_signatures anywhere 11:33 -!- tombusby [~tombusby@gateway/tor-sasl/tombusby] has joined #lightning-dev 11:52 < BlueMatt> ie https://github.com/lightningnetwork/lightning-rfc/issues/468 11:56 -!- rdymac [uid31665@gateway/web/irccloud.com/x-hpabhzzowgwnylvq] has quit [Quit: Connection closed for inactivity] 11:57 -!- Rootsudo [~textual@180.190.116.254] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 12:23 <+roasbeef> BlueMatt: relay the new bits? don't think it's landed yet, but it's the same bits just with a different interpretation now 12:24 <+roasbeef> it isn't capacity, but max htlc accepted over that direction 12:24 < BlueMatt> roasbeef: mostly cause its extra data packed on the end 12:24 < BlueMatt> and it did get merged into bolts 12:25 <+roasbeef> BlueMatt: you'd prob always need to store the ann sigs of the remote side, either in memory or persistently, we do persistently just to guard against nodes that don't retransmit the message 12:25 < BlueMatt> no you shouldnt? 12:25 <+roasbeef> ah must've missed that 12:25 <+roasbeef> you need to cache it _somewhere_ 12:25 < BlueMatt> only in your list-of-channels logic, essentially 12:26 < BlueMatt> but if you're being super lightweight and arent storing that you dont care much 12:26 < BlueMatt> cause everyone else will have it cached 12:26 -!- kallisteiros [scientist@gateway/vpn/privateinternetaccess/kallisteiros] has quit [Ping timeout: 268 seconds] 12:26 < BlueMatt> from what I can read in c-lightning it doesnt (though I presume it does in its channel/route db somewhere) 12:26 <+roasbeef> well i'm approaching from the PoV of do all you can in order to ensure the exchagne is reliable, if none do this, then it won't be 12:26 < BlueMatt> which is how I implemented it initially as well 12:26 <+roasbeef> if you drop if when you get it, and haven't sent it yet, how can you complete the handshake? 12:27 < BlueMatt> well my point is if the proposed addition were a MUST from the beginning it'd be reliable 12:27 < BlueMatt> as you can always recalculate your own sigs, obviously 12:27 < BlueMatt> and c-lightning appears to already impelment it as such 12:28 < BlueMatt> and its not a huge deal cause you still get at-least-one-side-announces just fine if its partially phased-in 12:28 <+roasbeef> i guess i'm getting more at retransmission here, that nodes should continually retransmit, some don't so it makes sense to cache it so that when you construct yours, you can send out the full an w/o waiting on them to retransmit 12:28 < BlueMatt> not to mention the new changes to channel_update will result in things not propagating until thats phased in anyway 12:28 < BlueMatt> so its definitely not worse 12:28 < BlueMatt> retransmit like retransmit your announce to your peers, or retransmit like on reconnect? 12:29 <+roasbeef> the ann sig on reconnect 12:29 < BlueMatt> cause on reconnect is separate and the requirement that you have to at least respond to the first announcement_sigs after reconnect handles that just fine 12:29 <+roasbeef> until it's been fully announced 12:29 < BlueMatt> thats completely seprate 12:29 < BlueMatt> you dont need storage for that as long as its post-lock 12:29 <+roasbeef> post-lock? 12:29 < BlueMatt> post both-sides-funding_locked 12:29 < BlueMatt> ie the proposed change 12:30 <+roasbeef> don't see how that changes the reliability requirement here, if your impl sends ann only one time, and the other side doesn't cache, then it's possible the chan will never actually be announced 12:30 < BlueMatt> the proposed change doesnt effect that you must at least send after a reconnect 12:31 < BlueMatt> if you assume no reconnect and everyone sends after they've both sent and received funding_locked both sides will see the announcements after they've sent and received funding_locked so they'll be fine 12:32 < BlueMatt> then because you dont change that you must also respond to the first announcement_sigs after reconnect (assuming you're post both-sides-funding_locked) then you dont break reliability there either in case things got lost in transmission 12:37 <+roasbeef> ofc it can break reliablity, assume the other side crashes as soon as it gets the message, then you never retransmit 12:37 < BlueMatt> huh? no, when you reconnect you do? or do you mean the higher-level channel_announcement-sent-to-peers 12:37 < BlueMatt> ? 12:37 < BlueMatt> my point is that that is separate 12:38 <+roasbeef> yeh i only care about ensuring this exchange is reliable, other things is like w/e as some async impl will likely vioalte it, but again you can recover from that with defensive meausres 12:38 < BlueMatt> my point is that the proposed change does *not* break reliability of generating a channel_announcement 12:38 < BlueMatt> and it simplifies channel logic 12:38 <+roasbeef> yes, i get that, just want to stress that both sides must always retransmit the ann sig 12:38 <+roasbeef> we've had issues with this in the past 12:38 < BlueMatt> storing the channel_announcement in a way that you can send it to your peers is a separate consideration 12:38 < BlueMatt> retransmit the ann sig on reconnect is separate 12:39 < BlueMatt> and already stated in its own text 12:39 <+roasbeef> i understand that, just stressing to ensure that impls do indeed retransmit that 12:39 <+roasbeef> the ordering thing isn't as big of a deal 12:39 < BlueMatt> yea, I'm not suggesting that that text be change 12:39 < BlueMatt> d 12:39 < BlueMatt> its there for good reason 12:39 < BlueMatt> I'm suggesting the text around at what time you have to be changed which is pretty seprate 12:47 < BlueMatt> roasbeef: you may want to chime in here: https://github.com/lightningnetwork/lightning-rfc/issues/469 since technically lnd implements it wrong, but I think the spec is just confused 12:50 <+roasbeef> yeh looks like that was never changed when we switched everything over to be 64bit as was 32bit in the past (amounts) 12:52 -lightningrfc:#lightning-dev- [lightning-rfc] TheBlueMatt opened pull request #470: Correct fee calculation in BOLT 7 (master...master) https://git.io/fAOag 13:03 -!- farmerwampum [~farmerwam@104.129.29.18] has quit [Ping timeout: 272 seconds] 13:03 -!- bitconner [~conner@64-71-8-130.static.wiline.com] has joined #lightning-dev 13:12 -!- tombusby [~tombusby@gateway/tor-sasl/tombusby] has quit [Ping timeout: 250 seconds] 13:13 -!- enemabandit [~enemaband@16.77.54.77.rev.vodafone.pt] has joined #lightning-dev 13:14 -!- tombusby [~tombusby@gateway/tor-sasl/tombusby] has joined #lightning-dev 13:20 -!- kallisteiros [scientist@gateway/vpn/privateinternetaccess/kallisteiros] has joined #lightning-dev 13:27 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 244 seconds] 13:28 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev 13:35 -!- enemabandit [~enemaband@16.77.54.77.rev.vodafone.pt] has quit [Remote host closed the connection] 13:42 -!- Kaizen_ [~kaizen_@cpe-172-116-160-42.socal.res.rr.com] has joined #lightning-dev 13:47 -!- Kaizen_ [~kaizen_@cpe-172-116-160-42.socal.res.rr.com] has quit [Ping timeout: 268 seconds] 14:28 -!- Rootsudo [~textual@180.190.116.254] has joined #lightning-dev 14:33 < kallisteiros> in lightning, will hubs have to open a channel with me, if i open a channel with them? 14:34 < kallisteiros> in order to route payments to me from other parties 14:34 < kallisteiros> and if so, how are they supposed to decide how much funds they need to allocate to me? 14:36 <+roasbeef> kallisteiros: channel right now are single funder, so nodes will need to decide out of band to open up a channel to your ot not 14:37 < kallisteiros> how would they decide? 14:37 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 244 seconds] 14:38 < kallisteiros> just guessing? 14:40 <+roasbeef> they wouldn't prob 14:40 <+roasbeef> depends really in the end 14:41 < kallisteiros> if they wouldn't, I'm completely screwed. in order to receive lightning payments, a channel must be established from the hub to me 14:41 < kallisteiros> long before I receive the payment 14:42 < kallisteiros> if it's on demand, the hub would have to open a channel with me, but I would have to wait until it confirms on chain, which is useless 14:43 < kallisteiros> I'm genuinely trying to understand, cause I'm working on a LN implementation, only for ethereum. what does a utopian LN future look like? what would it look like from the hub's side? 14:45 <+roasbeef> kallisteiros: nah you can shift around your funds yourself 14:45 <+roasbeef> well eth is pretty diff 14:45 <+roasbeef> also there's like 4 or 5 teams doing similar things on eth, why not join em? 14:46 < kallisteiros> because they're all going different directions, and I don't like either of those 14:47 < kallisteiros> what do you mean shift around my funds? I can shift around my funds, but how do I receive them in the first place via LN? 14:47 <+roasbeef> what don' tyou like about the direction they're going in? 14:47 < kallisteiros> assuming I don't have a direct channel with the sender opened 14:48 < kallisteiros> Raiden, for example, instead of doing LN with native ether, they do ERC20 transfers only 14:48 <+roasbeef> ok 1 down, 4 to go 14:48 < kallisteiros> Plasma is overcomplicated 14:49 < kallisteiros> for a simple LN that I need for my next project 14:49 < kallisteiros> it tries to run smart contracts etc. 14:49 < kallisteiros> I don't need that, I just need to move coins around fast 14:50 < molz> 2 down, 3 to go :D 14:50 < kallisteiros> oh come on. show me a simple LN implementation on Ethereum, if you know one 14:50 < kallisteiros> even state channels 14:51 < kallisteiros> or payment channels 14:51 < kallisteiros> between two participants 14:51 < kallisteiros> and yet it seems very easy to actually implement using smart contract language 14:51 < kallisteiros> much more flexible than bitcoin's Script, no offense 14:52 < kallisteiros> HTLCs are easier, multisigs are easier 14:53 < kallisteiros> surprised nobody did it yet 14:54 < kallisteiros> but this is off topic. I just wanted to understand the high level picture when hubs are involved 14:55 < molz> from what i understand the "hubs" idea isn't in the LN protocol 14:55 < molz> so you might as well stick with ETH 14:56 < kallisteiros> it's not in the protocol, but it's heavingly implied 14:56 < kallisteiros> it's a Lightning *Network*. why would anybody connect to you in the way that you would need several hops, and not directly? 14:57 < kallisteiros> to facilitate the offchain payments. so the relay nodes in between are what I call hubs here 14:58 < kallisteiros> LN was pitched as a solution to scalability problems, and hubs were a big part of the pitch 15:01 -!- contrapumpkin [~copumpkin@haskell/developer/copumpkin] has joined #lightning-dev 15:01 -!- copumpkin [~copumpkin@haskell/developer/copumpkin] has quit [Ping timeout: 240 seconds] 15:08 -!- sh_smith [~sh_smith@cpe-76-174-26-91.socal.res.rr.com] has quit [Remote host closed the connection] 15:12 < kallisteiros> *heavily 15:37 <+roasbeef> kallisteiros: you missed the actual teams 15:37 <+roasbeef> would go back and re-investigate the existing efforts 15:41 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 276 seconds] 15:41 <+roasbeef> kallisteiros: scripts are a _very_ small part of actually making something like LN, like the scripts are prob not even 5% of the LoC for impls 15:42 <+roasbeef> ppl always pitch that "oh vm makes it so much easier", but it's the case that most of the design and logic is related to the network component, not what scripts or how the vm you're using interacts with it 15:44 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #lightning-dev 15:46 < lndbot> kallisteiros, also don’t underestimate the difficulty of mutable accounts when moving to offchain protocols 15:48 < lndbot> iirc, many have recreated the utxo paradigm because it provides better L1 guarnatees 15:49 < lndbot> so using native ETH is difficult even, as it may have to be utxo-ified, and those conversions = more onchain txns 15:52 < kallisteiros> roasbeef: I didn't say scripts are the biggest part of LN, I just pointed out it's implementation is simpler and more flexible if additional constructs are needed 15:53 < kallisteiros> roasbeef: but even then, some things are just easier: routing problem? there's no problem, ethereum addresses represent the nodes themselves, so all that is needed is to scan the blockchain for opened channels and do a Dijkstra on them or something 15:54 < kallisteiros> Bitcoin is much more private with its utxo model and change addresses, but it makes things like routing harder 15:54 < kallisteiros> anyway, not roasting bitcoin here, never mind about that 15:54 <+roasbeef> uhh using eth acounts as nodes id's really doesn't simplify the problem at all, i'd go back and do a bit more research on the current state of things 15:56 <+roasbeef> approaching off topic land tho 15:56 < kallisteiros> it does though. if you scan the opened LN channels, which are public record, and you see 0x01 opened a channel to 0x05, and 0x05 opened a channel to 0xab, you know you can route 0x01 to 0xab through 0x05 15:56 <+roasbeef> why bloat the chain with that info when it can be obtained over a p2p channel? 15:57 < kallisteiros> you do it anyway, opening the channel on chain 15:57 < kallisteiros> only in BTC the address is constantly changing 15:57 <+roasbeef> you'd likely also need additional info to actually route, so again need to fetch from a network 15:57 <+roasbeef> dunno what you mean by the addr is constantly changing 15:58 < kallisteiros> don't know about any additional info. I would just calculate locally the path to the destination, and tell the closest node to me from that path to route it to the next hop 15:58 < kallisteiros> just like IP does you know 15:58 -!- sh_smith [~sh_smith@cpe-76-174-26-91.socal.res.rr.com] has joined #lightning-dev 15:59 < kallisteiros> BTC paradigm discourages from reuse of bitcoin addresses 15:59 < kallisteiros> and rightly so, it helps privacy 15:59 < kallisteiros> your change address is different from the input address 16:00 < kallisteiros> not so in ethereum, you have a constant account address which you are discouraged from changing 16:00 < kallisteiros> sucks for privacy, makes LN routing a charm 16:01 < kallisteiros> conner: I have no idea what you said about utxo in eth, "better L1 guarantees" etc and how it's applicable, sorry 16:02 < lndbot> might be something to look into before making vast oversimplifications in your model of how this is going to wokr 16:02 <+roasbeef> there are no addresses related to nodes, i'd check out the rfc docs first to get a handle on how things are set up atm 16:02 <+roasbeef> you're working at a very hgih level rigth now, and making simplyfing assumptions that actually don't matter in practice 16:02 < kallisteiros> conner: I know how it works, it doesn't need any "utxo-fication" or whatever, works fine already as is 16:03 < lndbot> looking forward to seeing a working demo then :slightly_smiling_face: 16:03 < kallisteiros> roasbeef: I've read docs and BOLT. there are no addresses, but there are node ids 16:03 < kallisteiros> in ethereum, node ids could be ethereum addresses from which the channels are being opened 16:04 < kallisteiros> hard to explain quickly, cause EVM is a different beast, so I would be confused too if I worked with bitcoin Script and utxo model mostly 16:05 <+roasbeef> makes no material diff, but this is pretty off topic, and would recommend you do a bit more research on that state of the related space 16:05 < kallisteiros> but the main point is, if I need to receive me some lightning, some node must open a channel to me 16:05 <+roasbeef> answer to that is false 16:06 < kallisteiros> and do it long before the actual payment, not knowing whether this payment will come at all and in what amount 16:06 -!- michaelsdunn1 [~michaelsd@unaffiliated/michaelsdunn1] has quit [Remote host closed the connection] 16:06 < kallisteiros> what do you mean false? that's the only way to receive a lightning payment, to have a channel opened 16:07 -!- michaelsdunn1 [~michaelsd@unaffiliated/michaelsdunn1] has joined #lightning-dev 16:07 -!- michaelsdunn1 [~michaelsd@unaffiliated/michaelsdunn1] has quit [Remote host closed the connection] 16:07 < kallisteiros> your way, not from you to the node, but from the node to you 16:08 < kallisteiros> why would they lock money in a channel with a stranger like me, I got no idea, that's the part I'm trying to understand 16:09 < kallisteiros> hoping to get some payment fees doesn't cut it; I can exhaust all such hub's funds by requesting a bunch of channels then 16:09 <+roasbeef> bbl will leave you to marinate on the answer 16:09 < molz> lol 16:10 < kallisteiros> well, thanks for trying, I'll wait for the correct one 16:11 < molz> he answer that you want to hear is the "correct one"? 16:11 < molz> s/he/the/ 16:13 < kallisteiros> it's the objectively correct one 16:14 < kallisteiros> he just said I don't have to have a channel opened my way to receive a lightning payment. do you agree to this too? 16:14 < kallisteiros> is this #ligthning-dev or what? this is like lightning 101 16:15 < molz> he's correct 16:15 < molz> i just got some payment from a coinjar that i don't have a channel to it, nor does it have a channel to me 16:16 < molz> you need to read the correct info again and stop reading garbage about LN 16:16 < kallisteiros> coinjar is the custodian of your funds in this case? 16:16 < molz> nope 16:19 < kallisteiros> I'd love to be proven incorrect on this one, but answers like "false" and "nope" don't help, you know 16:19 < kallisteiros> cause I could say "true" and "yep" to that 16:19 < lndbot> Kallisteiros you can open a channel to a random node, spend funds over that channel, and then receive LN payments over that channel in amounts less than you’ve spent. 16:21 < kallisteiros> r251d first, thanks for a more verbose response 16:23 < kallisteiros> I don't see a technical way to do that though 16:23 < kallisteiros> if it's a 2-of-2 multisig, this random node must sign the last transaction and broadcast it 16:23 < kallisteiros> I can't do this without this node's permission 16:23 < lndbot> You should re-read how bidirectional channels work. 16:23 < kallisteiros> (if we don't consider the timeout later) 16:31 < kallisteiros> r251d: might have missed this, will reread the paper. so instead of the node having to open a channel my way, it can just sign over back to me some of the funds I gave up earlier in my channel? and if I didn't spend any funds yet? 16:33 < kallisteiros> but at least it's more productive than hubs throwing money at random connections, this is a more interesting concept 16:33 < kallisteiros> thanks for pointing me in this direction 16:37 < kallisteiros> still no idea what molz said that though. "i just got some payment from a coinjar that i don't have a channel to it, nor does it have a channel to me" 16:37 < molz> right 16:38 < molz> it just means i have a channel with someone who probably has a channel with the coinjar and has liquidity to forward the payment 16:39 < kallisteiros> and that's exactly what I said, "if I need to receive me some lightning, some node must open a channel to me" 16:39 < kallisteiros> I didn't say the sender. actually, it wouldn't be the sender in most cases 16:39 < molz> in the absolute sense? 16:40 < kallisteiros> r251d pointed out to me that the direction have to be from the node to me, must read up on that 16:40 < lndbot> I don’t get why anyone would bother with implementing a trust-minimizing payment layer on Eth when so few people can run a Eth node trustlessly. 16:40 < lndbot> Don’t you need a trustless base layer to implement a trustless payment layer on top of it? 16:40 < kallisteiros> cause of blockchain size, right? 16:40 < lndbot> Yeah, not storage size, but time to validate the chain. 16:41 < kallisteiros> doesn't bitcoin have checkpoints and `assumeValid` directive as well? 16:42 < kallisteiros> modern bitcoin full node doesn't validate transactions up to some hardcoded height, in assumeValid, forgot the exact number 16:42 < lndbot> I guess this is off topic for this channel, but assumeValid requires trusting someone to tell you what tip is valid, so that’s not really working in a trustless way. 16:43 -!- Emcy [~Emcy@unaffiliated/emcy] has quit [Remote host closed the connection] 16:43 < lndbot> Anyway, I’ll drop this topic here because it’s off topic. 16:44 < kallisteiros> right 16:44 -!- Emcy [~Emcy@unaffiliated/emcy] has joined #lightning-dev 16:45 < lndbot> assume valid is only for signatures iirc, the txns are otherwise still validated and applied to the utxo set 16:46 < lndbot> it doesn’t just blindly trust assumevalid either 16:46 < kallisteiros> don't you need to run scriptPubKey + scriptSig to validate the signatures? 16:47 < kallisteiros> and if we skip that, not much less left 16:47 < kallisteiros> *not much left 16:47 < lndbot> I believe it’s all script execution 16:48 < lndbot> assumevalid still checks work, it’s not a checkpoint 16:48 < kallisteiros> what I'm trying to say is, the same is true for ethereum, there is a fast sync where only the headers and PoW is validated until the node catches up with everyone else, and then the full validation starts 16:49 < lndbot> you also validate inputs, outputs amts <= iput amts, which is important 16:49 < kallisteiros> it doesn't need to go very deep, since it's not a utxo system, but rather a merkle tree, where each transaction changes the leaves 16:49 < lndbot> those are not the same thing, sorry 16:50 < lndbot> You could say that SPV is similar because it skips over checking everything 16:50 < kallisteiros> not the same, different mechanisms, I agree. anyway, not an expert on validation modes in eth, so... I reckon there's like 7 or 8 different modes 16:50 < lndbot> I’m not sure fast sync is even as good as SPV though 16:50 < lndbot> i think it probabilistically validates PoW too? 16:50 < kallisteiros> alexbosworth: yeah, cause SPV relies on the fact that nobody would spend so much hashpower mining on the incorrect block 16:51 < kallisteiros> that the full nodes would reject 16:51 < lndbot> like 1/10k 16:51 < lndbot> Not a great assumption given that we have forks sharing hash functions 16:51 < kallisteiros> why probabilistically? it checks that the hash is under the proper difficulty 16:52 < lndbot> because ethhash is super heavy, esp on resource constrained devices w/ not much memory 16:52 < lndbot> You can spot check blocks with SPV at least 16:52 < kallisteiros> you just need to do it once for each block, not mine them 16:52 < lndbot> Not sure that is possible with ETH due to the state changes 16:53 -!- itaseski [~itaseski@213.135.176.114] has quit [Ping timeout: 252 seconds] 16:55 < kallisteiros> is this lndbot integrated to a lightning client or something? 16:56 < molz> kallisteiros, if you have questions about "assumevalid", i would suggest to ask in channel #bitcoin, and currently a dev is active there, best time to ask, he'll explain well to you because he's the one that created that PR, iirc 16:57 -!- Kaizen_ [~kaizen_@2605:a601:b021:f00:5c96:6a8a:39c4:a002] has joined #lightning-dev 16:57 < molz> and for the record, "assumevalid" makes syncing a new bitcoind node go really fast, but it's offtopic here 16:59 < kallisteiros> it's fine, thanks. I got the gist of it from the 0.14.0 changelog when it got introduced 16:59 -!- Kaizen_ [~kaizen_@2605:a601:b021:f00:5c96:6a8a:39c4:a002] has quit [Remote host closed the connection] 17:03 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 244 seconds] 17:04 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #lightning-dev 17:05 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #lightning-dev 17:13 -!- kallisteiros [scientist@gateway/vpn/privateinternetaccess/kallisteiros] has quit [Ping timeout: 244 seconds] 17:25 -!- HFRadical [~none@91.214.169.69] has quit [Quit: Leaving] 17:27 -!- Kaizen_ [~kaizen_@2605:a601:b021:f00:5c96:6a8a:39c4:a002] has joined #lightning-dev 17:40 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 252 seconds] 17:55 -!- wraithm [~wraithm@unaffiliated/wraithm] has joined #lightning-dev 17:57 -!- Kaizen_ [~kaizen_@2605:a601:b021:f00:5c96:6a8a:39c4:a002] has quit [Remote host closed the connection] 18:19 -!- gescoe [31cf38fd@gateway/web/freenode/ip.49.207.56.253] has joined #lightning-dev 18:19 -!- gescoe [31cf38fd@gateway/web/freenode/ip.49.207.56.253] has quit [Client Quit] 18:30 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [] 18:59 -!- unixb0y [~unixb0y@p2E5558D0.dip0.t-ipconnect.de] has quit [Ping timeout: 268 seconds] 19:00 -!- unixb0y [~unixb0y@p2E555CBA.dip0.t-ipconnect.de] has joined #lightning-dev 19:01 -!- riclas [riclas@148.63.37.111] has quit [Ping timeout: 244 seconds] 19:24 -!- bitconner [~conner@64-71-8-130.static.wiline.com] has quit [Ping timeout: 252 seconds] 19:34 -!- bitconner [~conner@64-71-8-130.static.wiline.com] has joined #lightning-dev 19:39 -!- bitconner [~conner@64-71-8-130.static.wiline.com] has quit [Ping timeout: 268 seconds] 19:57 -!- Kaizen_ [~kaizen_@2605:a601:b021:f00:8452:74d2:538b:f265] has joined #lightning-dev 20:02 -!- Kaizen_ [~kaizen_@2605:a601:b021:f00:8452:74d2:538b:f265] has quit [Ping timeout: 264 seconds] 20:28 -!- dougsland [~douglas@c-73-234-93-65.hsd1.nh.comcast.net] has quit [Ping timeout: 252 seconds] 20:29 -!- bitconner [~conner@64-71-8-130.static.wiline.com] has joined #lightning-dev 20:37 -!- bitconner [~conner@64-71-8-130.static.wiline.com] has quit [Ping timeout: 268 seconds] 20:59 -!- Urgo_ [~Urgo@cpe-107-15-142-254.nc.res.rr.com] has joined #lightning-dev 20:59 -!- Urgo [~Urgo@cpe-107-15-142-254.nc.res.rr.com] has quit [Disconnected by services] 20:59 -!- Urgo_ [~Urgo@cpe-107-15-142-254.nc.res.rr.com] has quit [Excess Flood] 20:59 -!- Urgo [~Urgo@cpe-107-15-142-254.nc.res.rr.com] has joined #lightning-dev 20:59 -!- Urgo [~Urgo@cpe-107-15-142-254.nc.res.rr.com] has quit [Excess Flood] 21:00 -!- Urgo [~Urgo@cpe-107-15-142-254.nc.res.rr.com] has joined #lightning-dev 21:26 -!- gernot [~gernot@unaffiliated/gernot] has quit [Quit: WeeChat 1.6] 21:27 -!- bitconner [~conner@64-71-8-130.static.wiline.com] has joined #lightning-dev 21:46 -!- Rootsudo [~textual@180.190.116.254] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 21:46 -!- Rootsudo [~textual@180.190.116.254] has joined #lightning-dev 21:47 -!- Rootsudo [~textual@180.190.116.254] has quit [Client Quit] 21:47 -!- Rootsudo [~textual@180.190.116.254] has joined #lightning-dev 21:49 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 244 seconds] 21:55 -!- Rootsudo [~textual@180.190.116.254] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 21:56 -!- Rootsudo [~textual@180.190.116.254] has joined #lightning-dev 21:56 -!- Rootsudo [~textual@180.190.116.254] has quit [Client Quit] 21:56 -!- Rootsudo [~textual@180.190.116.254] has joined #lightning-dev 21:57 -!- Rootsudo [~textual@180.190.116.254] has quit [Client Quit] 21:58 -!- Rootsudo [~textual@180.190.116.254] has joined #lightning-dev 21:58 -!- Rootsudo [~textual@180.190.116.254] has quit [Client Quit] 21:59 -!- Rootsudo [~textual@180.190.116.254] has joined #lightning-dev 21:59 -!- Rootsudo [~textual@180.190.116.254] has quit [Client Quit] 22:03 -!- shesek [~shesek@bzq-84-110-232-211.red.bezeqint.net] has joined #lightning-dev 22:03 -!- shesek [~shesek@bzq-84-110-232-211.red.bezeqint.net] has quit [Changing host] 22:03 -!- shesek [~shesek@unaffiliated/shesek] has joined #lightning-dev 22:08 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev 22:42 -!- bitconner [~conner@64-71-8-130.static.wiline.com] has quit [Ping timeout: 244 seconds] 22:56 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #lightning-dev 23:20 -!- ebx [~ebx@unaffiliated/ebex] has quit [Remote host closed the connection] 23:26 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 268 seconds] 23:50 -!- Rootsudo [~textual@180.190.112.33] has joined #lightning-dev