--- Log opened Mon Aug 05 00:00:30 2019
00:17 -!- melvster [~melvin@ip-86-49-18-190.net.upcbroadband.cz] has joined #lightning-dev
00:25 -!- enemabandit [~enemaband@185.227.37.188.rev.vodafone.pt] has joined #lightning-dev
00:27 -!- enemabandit [~enemaband@185.227.37.188.rev.vodafone.pt] has quit [Client Quit]
00:35 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
00:38 -!- laptop500 [~laptop@host81-147-158-108.range81-147.btcentralplus.com] has joined #lightning-dev
00:55 -!- shesek` [~shesek@141.226.218.109] has quit [Ping timeout: 258 seconds]
01:08 -!- kam270_ [~kam270@183.182.104.69] has quit [Ping timeout: 268 seconds]
01:17 -!- sstone [~sstone@irc.acinq.fr] has joined #lightning-dev
01:26 -!- pm7 [pm7@gateway/shell/mydevil.net/x-fnpbfokmmsyvsuat] has quit [Quit: No Ping reply in 180 seconds.]
01:27 -!- __gotcha [~Thunderbi@plone/gotcha] has joined #lightning-dev
01:27 -!- pm7 [pm7@gateway/shell/mydevil.net/x-uzcumeswkjmigpsv] has joined #lightning-dev
01:42 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 246 seconds]
01:51 -!- queip [~queip@unaffiliated/rezurus] has joined #lightning-dev
02:18 -!- kam270 [~kam270@183.182.104.69] has joined #lightning-dev
02:19 -!- mauz555 [~mauz555@2a01:e35:8ab1:dea0:5979:e530:9381:2894] has joined #lightning-dev
02:20 -!- kam270 [~kam270@183.182.104.69] has quit [Read error: Connection reset by peer]
02:21 -!- jungly [~quassel@host97-200-static.8-79-b.business.telecomitalia.it] has joined #lightning-dev
02:22 -!- __gotcha1 [~Thunderbi@plone/gotcha] has joined #lightning-dev
02:25 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Ping timeout: 272 seconds]
02:25 -!- __gotcha1 is now known as __gotcha
02:44 -!- riclas [riclas@77.7.37.188.rev.vodafone.pt] has joined #lightning-dev
02:50 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 248 seconds]
02:58 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Ping timeout: 248 seconds]
03:04 -!- shesek` [~shesek@141.226.152.112] has joined #lightning-dev
03:10 -!- queip [~queip@unaffiliated/rezurus] has joined #lightning-dev
03:13 -!- __gotcha [~Thunderbi@plone/gotcha] has joined #lightning-dev
03:27 -!- mauz555 [~mauz555@2a01:e35:8ab1:dea0:5979:e530:9381:2894] has quit []
03:36 -!- shesek` [~shesek@141.226.152.112] has quit [Ping timeout: 248 seconds]
03:52 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Ping timeout: 268 seconds]
03:59 -!- melvin_ [~melvin@ip-86-49-18-190.net.upcbroadband.cz] has joined #lightning-dev
03:59 -!- melvster [~melvin@ip-86-49-18-190.net.upcbroadband.cz] has quit [Read error: Connection reset by peer]
03:59 -!- __gotcha [~Thunderbi@plone/gotcha] has joined #lightning-dev
04:01 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Quit: = ""]
04:25 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Ping timeout: 245 seconds]
04:43 -!- __gotcha [~Thunderbi@plone/gotcha] has joined #lightning-dev
04:57 -!- __gotcha1 [~Thunderbi@plone/gotcha] has joined #lightning-dev
05:01 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Ping timeout: 244 seconds]
05:01 -!- __gotcha1 is now known as __gotcha
05:59 -!- ccdle12 [~ccdle12@cpc139350-aztw33-2-0-cust310.18-1.cable.virginm.net] has joined #lightning-dev
06:30 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 268 seconds]
06:39 -!- queip [~queip@unaffiliated/rezurus] has joined #lightning-dev
06:52 -!- sstone [~sstone@irc.acinq.fr] has quit [Quit: Leaving]
07:21 -!- _Sam-- [~greybits@unaffiliated/greybits] has quit [Read error: Connection reset by peer]
07:40 -!- mdunnio [~mdunnio@38.126.31.226] has joined #lightning-dev
07:43 -!- mdunnio [~mdunnio@38.126.31.226] has quit [Remote host closed the connection]
07:54 -!- mdunnio [~mdunnio@38.126.31.226] has joined #lightning-dev
07:56 -!- mdunnio [~mdunnio@38.126.31.226] has quit [Remote host closed the connection]
07:57 -!- mdunnio [~mdunnio@38.126.31.226] has joined #lightning-dev
08:48 -!- mdunnio [~mdunnio@38.126.31.226] has quit [Remote host closed the connection]
08:51 -!- mdunnio [~mdunnio@38.126.31.226] has joined #lightning-dev
09:06 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined #lightning-dev
09:30 -!- mdunnio [~mdunnio@38.126.31.226] has quit [Remote host closed the connection]
09:45 -!- mdunnio [~mdunnio@38.126.31.226] has joined #lightning-dev
09:50 -!- mdunnio [~mdunnio@38.126.31.226] has quit [Ping timeout: 246 seconds]
10:01 -!- mdunnio [~mdunnio@38.126.31.226] has joined #lightning-dev
10:06 -!- mdunnio [~mdunnio@38.126.31.226] has quit [Ping timeout: 272 seconds]
10:08 -!- jungly [~quassel@host97-200-static.8-79-b.business.telecomitalia.it] has quit [Remote host closed the connection]
10:08 -!- mdunnio [~mdunnio@38.126.31.226] has joined #lightning-dev
10:10 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Ping timeout: 245 seconds]
10:25 -!- deafboy [quasselcor@cicolina.org] has quit [Quit: deafboy]
10:38 -!- captjakk [~captjakk@c-65-50-169-164.hs.gigamonster.net] has joined #lightning-dev
10:44 -!- __gotcha [~Thunderbi@plone/gotcha] has joined #lightning-dev
10:45 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #lightning-dev
10:47 -!- tryphe_ [~tryphe@unaffiliated/tryphe] has joined #lightning-dev
10:47 -!- tryphe [~tryphe@unaffiliated/tryphe] has quit [Ping timeout: 248 seconds]
10:49 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Ping timeout: 245 seconds]
10:49 -!- __gotcha [~Thunderbi@plone/gotcha] has joined #lightning-dev
11:18 -!- mdunnio [~mdunnio@38.126.31.226] has quit [Remote host closed the connection]
11:19 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Ping timeout: 268 seconds]
11:28 -!- mdunnio [~mdunnio@38.126.31.226] has joined #lightning-dev
11:30 -!- jimpo [~jimpo@ec2-13-57-39-52.us-west-1.compute.amazonaws.com] has joined #lightning-dev
11:37 < BlueMatt> hmmm, I guess no more lightning IRC meetings :(
11:37 < BlueMatt> roasbeef: ?
11:54 -!- tryphe_ [~tryphe@unaffiliated/tryphe] has quit [Remote host closed the connection]
11:55 -!- tryphe_ [~tryphe@unaffiliated/tryphe] has joined #lightning-dev
12:00 < Chris_Stewart_5> BlueMatt: IIRC they moved them back like 1 or 2 hours 
12:00 < Chris_Stewart_5> It would be nice to have them in the channel description :-)
12:01 < lndbot> <moli> i think the meeting starts @ 13:00 PST
12:02 < BlueMatt> ah
12:02 < BlueMatt> i guess I'll miss them
12:03 < BlueMatt> or, today's
12:08 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 246 seconds]
12:15 -!- queip [~queip@unaffiliated/rezurus] has joined #lightning-dev
12:18 -!- melvin_ [~melvin@ip-86-49-18-190.net.upcbroadband.cz] has quit [Ping timeout: 248 seconds]
12:21 -!- mdunnio [~mdunnio@38.126.31.226] has quit [Remote host closed the connection]
12:26 -!- mdunnio [~mdunnio@38.126.31.226] has joined #lightning-dev
12:36 -!- melvster [~melvin@ip-86-49-18-190.net.upcbroadband.cz] has joined #lightning-dev
12:36 < bitconner> Chris_Stewart_5: meeting time can shift by 2 hrs over the course of the year due to day light savings
12:45 -!- t-bast [~t-bast@2a01:e34:ec2c:260:510e:a6d0:4632:adce] has joined #lightning-dev
12:48 < cdecker> BlueMatt: it gets moved back 2 hours in summer since DST moves in opposite directions on the two hemispheres
12:48 < cdecker> (Fun with timezones...)
12:52 -!- hiroki_ [cad6a796@150.167.214.202.rev.vmobile.jp] has joined #lightning-dev
12:53 < bitconner> we might have permanent DST here in california pretty soon
12:53 < bitconner> maybe rusty can petition his local municipality :)
12:55 -!- sstone [~sstone@185.186.24.109.rev.sfr.net] has joined #lightning-dev
12:56 < Emzy> I would love to have no day light savings. It may stop Germany sone day...
12:57 < Emzy> be stopped
12:58 -!- nkohen [~nkohen@2601:282:4101:9356:98e9:d895:822c:6cdc] has joined #lightning-dev
12:59 < niftynei> arizona doesn't do DST, which admittedly was a bit confusing when flying through phoenix
12:59 -!- mdunnio [~mdunnio@38.126.31.226] has quit [Remote host closed the connection]
12:59 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev
13:00 < t-bast> hello everyone
13:00  * bitconner waves
13:01 < sstone> hi!
13:01 < lndbot> <joost.jager> hi
13:01 < rusty> Hello all!  ISTR bitconner was volunteered to chair today?
13:01 < t-bast> Exactly ;)
13:02 < t-bast> Were you aware bitconner?
13:02 < cdecker> Hi all ^^
13:02 < bitconner> yes! link??
13:03 < t-bast> http://wiki.debian.org/MeetBot
13:03 < cdecker>  http://wiki.debian.org/MeetBot
13:03 < niftynei> ;D
13:03 < t-bast> lightning fast
13:03 < bitconner> thanks!
13:03 < bitconner> #startmeeting
13:03 < lightningbot> Meeting started Mon Aug  5 20:03:33 2019 UTC.  The chair is bitconner. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:03 < lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
13:03 < bitconner> any thing people would like to prioritize first?
13:04 < t-bast> Maybe 557 since Rusty was able to make progress?
13:04 < t-bast> We also have a bunch of small ones with discussions pending
13:04 < bitconner> #topic extend channel range queries https://github.com/lightningnetwork/lightning-rfc/pull/557
13:04 < rusty> Yeah, let's clear some brush...
13:05 < rusty> So, it's actually a pretty simple change, TBH.  There's one outstanding q: do we use the same encoding-byte-then-stream style for checksums or not?
13:06 < rusty> The test vectors don't, but the spec was modified to do so.  I think not, actually: it's a bit neater without it.
13:06 < rusty> But I don't really mind.
13:06 < sstone> do you think we'll ever need to compress checksums ? if not then let's just remove the encoding prefix
13:06 <+roasbeef> what's byte then stream mean? 
13:07 < rusty> roasbeef: like we do for short-channel-ids, one byte to say uncompressed/zlib, then the series of scids.
13:08 < rusty> roasbeef: doesn't make as much sense for checksums, except we use 0 for "no channel update received".  I think that's a bit unusual tho.
13:08 < bitconner> does seem unlikely that we would try to compress checksums
13:09 < bitconner> don't have a strong preference either way, but seems there's some general agreement to drop the encoding type?
13:09 < t-bast> It's unlikely that we would compress individual checksums but wouldn't it make sense to compress a whole array of checksums?
13:09 < t-bast> It's an open question, I'm a bit new to that part of the codebase
13:10 < sstone> not unless we have a lot of 0s (ie channels for which we only have 1 channel update and not 2)
13:10 < rusty> Spec is a bit clearer as '...*channel_update_checksums'.  It's a line-ball, can sstone comment?
13:11 < sstone> if possible, something like compress(array(type)) or compressed*array*type would be even clearer
13:11 < sstone> but I don't know how hard that would be to parse (I guess parenthesis would make things harder)
13:12 < rusty> (FWIW, I implemented both, so it's trivial for me).  We've got -rc1 in 4 days, so I was planning on including this as an --enable-experimental-features.
13:12 < sstone> yes ! :)
13:12 < rusty> sstone: well, formatting can be cleaned up later I guess?
13:12 < rusty> sstone: your call, I think.
13:12 < t-bast> agreed that formatting can be changed later
13:13 < sstone> yes of course
13:13 -!- captjakk [~captjakk@c-65-50-169-164.hs.gigamonster.net] has quit [Remote host closed the connection]
13:14  * rusty imagines sstone flipping a coin...
13:14 < sstone> so I'll change the description of the TLV to `...*`
13:14 < t-bast> so the rough consensus is to drop the encoding byte for checksums and go with the latest version of the PR and test compatibility between CL and eclair?
13:14 -!- captjakk [~captjakk@c-65-50-169-164.hs.gigamonster.net] has joined #lightning-dev
13:14 < t-bast> And clean-up formatting later if needed
13:14 < bitconner> sgtm
13:14 < rusty> ack.
13:14 < bitconner> #action drop checksum encoding type and clean up formatting
13:14 <+roasbeef> imo the compression could prob be left off all together, impls are forced to bring in compression libs and impl defensive measures agaisnt them (and the additional surface area), just to save on some round trip times 
13:14 < sstone> sgtm
13:14 < t-bast> great, very cool if that's included in your rc1 rusty!
13:14 <+roasbeef> but we'll prob just impl decoding again, but not sending 
13:15 < t-bast> good point roasbeef
13:15 < rusty> The commit needs some minor attention: the test vectors are in a comment, should be in an appendix.  But minor stuff.
13:15 < sstone> yes I'll move the test vectors to a separate file
13:15 < rusty> roasbeef: yes, we have that problem already though.
13:15 < bitconner> #topic merge final_expiry_too_soon into incorrect_or_unknown_payment https://github.com/lightningnetwork/lightning-rfc/pull/608
13:16 <+roasbeef> yeah, and imo the same argument applies there, with teh current graph size, we still do multiple RTTs 
13:16 < rusty> I do want to ask for a feature bit: it's unnecessary, but useful to flag it.
13:16 < sstone> and I'll add a feature bit too
13:16 < t-bast> #action add feature bit 
13:16 < rusty> sstone: OK, take the next pair, please, since this is basically approved.
13:17 < sstone> that would be 50/51 right ?
13:17 < rusty> 10/11?
13:17 < t-bast> yep 10/11
13:18 < t-bast> you get to steal it from a not-implemented-yet feature ;)
13:18 -!- mdunnio [~mdunnio@38.126.31.226] has joined #lightning-dev
13:18 < sstone> ah ok yes
13:18 -!- captjakk [~captjakk@c-65-50-169-164.hs.gigamonster.net] has quit [Ping timeout: 246 seconds]
13:18 < bitconner> cool, i think this is gtg then
13:18 <+roasbeef> wilkl it be a global? since can be helpful to seek out just these nodes 
13:19 < bitconner> roasbeef: in my mind, yes
13:19 < sstone> yes it makes sense
13:19 < t-bast> agreed that it make sense to have it be a global
13:20 < t-bast> just to be clear, do have an agreement to merge this PR (and lock the feature flags / format) once the small nits are addressed?
13:20 < rusty> No, because all bits will be advertized, so everything is "global" in that sense?
13:20 < rusty> https://github.com/lightningnetwork/lightning-rfc/issues/605#issuecomment-518383654
13:20 <+roasbeef> well tehre's connection lvl vs node lvl 
13:20 < rusty> t-bast: ack.
13:20 <+roasbeef> connection level is like ephemeral stuff, like initila_routing_table_dump (or w/e it is) 
13:20 <+roasbeef> i think that's our only *true* connection level feature 
13:20 < rusty> roasbeef: but we're (probably, eventually, after bikeshedding!) going to mirror those in node_announcement.
13:20 < t-bast> roasbeef: sounds like we'll start discussing feature bit unification and naming now ;)
13:20 < rusty> roasbeef: sure.
13:20 <+roasbeef> everything else could be used for preferential node selection 
13:21 < bitconner> shall we move on to final_expiry_too_soon and circle back on minor details towards the end?
13:21 < t-bast> bitconner: sgtm
13:21 < rusty> bitconner: ack
13:21 < bitconner> t-bast: last i looked the pr was in good shape, will give another pass but i'd say probably in good shape
13:22 < bitconner> joost: do you want to update us on 608?
13:22 < t-bast> bitconner: cool thanks
13:22 < t-bast> 608 looks good to me, we're removing privacy leaks via error code one after the other ;)
13:22 < lndbot> <joost.jager> nothing changed, just rebased on top of the new data types
13:22 <+roasbeef> we've implemented 608 on our end as well 
13:22 < lndbot> <joost.jager> it fixes a probe vector and allows us to get more details in the final expiry too soon case
13:22 < bitconner> great, iirc we all thought it was a good change prior
13:22 < t-bast> I think that at some point we will just have a "payment_failed" error to avoid leaking information
13:23 < lndbot> <joost.jager> we reach that point after this pr is merged I think
13:23 < cdecker> Yeah, but for now having extra information is really useful for debugging ^^
13:23 < t-bast> cdecker: totally agree
13:23 < t-bast> joost: oh already that's the last one?
13:23 < lndbot> <joost.jager> wasn't that true for the previous fix (amt) too ?
13:23 < t-bast> yes definitely
13:23 < lndbot> <joost.jager> it is debugging info vs privacy
13:24 < bitconner> privacy > debugging
13:24 < lndbot> <joost.jager> and in this case also debugging info vs better payment reliability in a way
13:24 < rusty> Ack 608, FWIW.
13:24 < t-bast> true that the added blockchain height info can be useful for smarter retries
13:24 < lndbot> <joost.jager> (because we know whether the failure was caused by wrong details or delaying nodes on the forward path. in the former we can give up, while in the latter we can try another route)
13:24 < t-bast> ACK for me too
13:25 < bitconner> cool, approved
13:25 < sstone> FWIW we still have the `error` messages that leaks info on which version of which impl you're using 
13:25 < t-bast> we briefly touched on 571 (feature bit unification), shall we do that next?
13:26 < cdecker> Yep
13:26 < bitconner> mpp?
13:26 < bitconner> #topic base amp https://github.com/lightningnetwork/lightning-rfc/pull/643
13:26 < bitconner> floor is yours rusty :)
13:27 <+roasbeef> sstone: we had actual error codes before, but then they ended up falling off for some reason (original lnd had it), we need them again imo 
13:27 < rusty> OK, so roasbeef raised a good point on this PR.  We have a current issue with invoices with no amount, that intermediaries can probe and steal funds.
13:27 <+roasbeef> but there's also a lot of other tagging vectors as well 
13:27 < bitconner> t-bast: oops missed your message, switching to feature bits
13:27 < t-bast> I think roasbeef's suggested fix is simple and makes sense
13:27 < t-bast> bitconner: no worries, we can do that afterwards :)
13:28 < bitconner> sgtm
13:28 < bitconner> t-bast: referring to including a random id?
13:28 < t-bast> yes
13:28 <+roasbeef> yeh then you include it, and the reciver verifies 
13:28 < rusty> That's orthogonal to base amp, though.  I'll open a separate issue.
13:28 <+roasbeef> for e2e security, the intermediate can't guess that value (is the asumption) 
13:28 < bitconner> agreed. this will likely be shared with sss amp as well
13:29 < lndbot> <joost.jager> and is useful for plain regular payments as well?
13:29 < rusty> Yeah, a nonce.  It's no longer needed once we're Scriptless Scripts but it's good for now.
13:29 <+roasbeef> also on this topic, we had this old PR for what's now known as "keysend", we considered having it be a distinct elemtn in the protocol, but then realized it's basically just AMP with a total payment shard size of 1 
13:29 <+roasbeef> yep, a hold over till dlog stuff (on the nonce) 
13:29 <+roasbeef> joost: yeah regular payments can also include it also 
13:30 < t-bast> can you provide a link to that keysend thing?
13:30 < bitconner> roasbeef: this was noted in our original email :)
13:30 < lndbot> <joost.jager> also fixes probe vectors where intermediaries start crafting routes on their own to figure things out
13:30 < bitconner> t-bast: https://github.com/lightningnetwork/lnd/pull/2455
13:30 < rusty> Cool, I'll open a separate PR, picking some unassigned bolt11 field, and some new TLV field.  I'll let invoicer choose length, roasbeef?
13:30 < t-bast> thx
13:31 <+roasbeef> t-bast: old version was just having the pre-image in the onion at the end, here's our PR: https://github.com/lightningnetwork/lnd/pull/2455
13:31 < t-bast> oh ok, got it
13:32 < rusty> meanwhile, back at base amp...
13:32 < bitconner> #action rusty to make pr for payment nonces
13:32 < t-bast> so adding this nonce is orthogonal to 643 and should be done in a separate PR?
13:32 < bitconner> why exactly is it orthogonal?
13:33 < t-bast> that was a question :)
13:33 < cdecker> roasbeef: re keysend: have you seen the nice trick we did with the shared_secret from the onion-decoding for spontaneous payments?
13:33 < cdecker> That allows us not to include anything other than a signal in the onion itself :-)
13:33 < t-bast> cdecker: you're using the shared secret with the last hop to implicitly derive a preimage?
13:33 < rusty> bitconner: it's orthogonal because it's a problem already, nothing to do with MPP.
13:33 < rusty> (Any no-value-specified invoice has this issue)
13:34 < cdecker> t-bast: yes, that's the proposal we talked about at CoreDev
13:34 < cdecker> (might need to write it up...)
13:34 < bitconner> rusty: got it, thanks
13:34 <+roasbeef> cdecker: yeah, but we realized we can just compress that into a amp of shard one, so then it's just included, and less similar-ish stuff in the spec 
13:35 < rusty> Note that there's a "split the bill" mode of using MPP that I'm trying to preserve, where the parts are paid by different nodes.
13:35 <+roasbeef> and it's nice to be able to also drop off additional info, so like an account ID or something 
13:35 <+roasbeef> rusty: woudl require some coordination, so you could give htem the nonce at that point 
13:35 < cdecker> roasbeef: but the shared secret trick works with all payment mechanisms, no need for moon-math xD
13:36 <+roasbeef> xor is moon math? ;) 
13:36 < bitconner> lol
13:36 < rusty> roasbeef: I was going to include it in a new bolt11 field...
13:36 < t-bast> rusty: for the split the bill scenario, we can simply let every payer derive something randomly from the shared nonce (from the invoice) and send what randomness they used to derive
13:36 <+roasbeef> rusty: well could be like: proposer has a QR code, to coordinate w/ everyone at lunch, and that includes the invociec or something 
13:37 < cdecker> lol, I might be mixing up which AMP you mean then. I'll write it up and we can discuss on the PR (will stop hijacking the discussion now)
13:37 < t-bast> and the recipient can verify all shares were using something generated from the invoice's nonce, but different for each payer
13:37 <+roasbeef> cdecker: so this is just preimage = rand1 xor rand2 xor realThing
13:38 < bitconner> split the bill already requires coordination to decide how much everyone pays, no?
13:38 <+roasbeef> i think i have a good grip on what yuo're proposing, in the end still useful to have additional meta data, and we can have a single method for spontanoues stuff rather than like 3 (hence the death of keysend) 
13:38 < rusty> OK, so there are some interesting things in the PR, I think it needs more commenting on issue, FWIW.
13:38 < bitconner> rusty: tbh i haven't had a chance to read it in depth :/
13:39 < rusty> bitconner: TBH I'm just reading joost's comments now... :)
13:39 < t-bast> roasbeef: totally agree that it's a good time to regroup and make sure we all do the same thing :)
13:39 < bitconner> #action continue discussion/review on pr
13:40 < bitconner> #topic feature bit unification and renaming https://github.com/lightningnetwork/lightning-rfc/pull/571
13:40 < bitconner> seems most of the discussion is still about naming :P
13:40 < t-bast> FWIW I implemented 643 for eclair, it's quite simple to integrate, if CL has it in an experimental-feature in the next release I would be interested in testing interoperability
13:41 < bitconner> t-bast: nice, we are also planning to start implementing in the neart term
13:42 < rusty> t-bast: we never got the bikeshedding session we wanted with roasbeef on names local/global/node/channel feature naming ...
13:42 < t-bast> bitconner: cool, this is going to ship very quickly ;)
13:42 < t-bast> rusty: true, but we have many proposals on the PR right now don't we?
13:42 < t-bast> and we can still find new ones until everyone is satisfied
13:43 < bitconner> rusty: shall we defer naming discussion to the pr?
13:43 < bitconner> can make a todo for roasbeef :)
13:43 < rusty> t-bast, bitconner: ack.
13:43 < bitconner> #action roasbeef to weight in on feature field naming
13:43 < bitconner> alright
13:44 < bitconner> let's do an easy one
13:44 < bitconner> #topic single-option large channel https://github.com/lightningnetwork/lightning-rfc/pull/596
13:45 < bitconner> needs a rebase, feature bits might be a little out of date since variable payload went in
13:45 < bitconner> also depends on feature bit unification?
13:46 < t-bast> yes this depends on feature bit unification, but I think other than that it only needs a small rebase and everyone agrees on the intent?
13:47 -!- captjakk [~captjakk@c-65-50-169-164.hs.gigamonster.net] has joined #lightning-dev
13:47 < rusty> It tries to do too much.  It adds enforcement of the channel limit in channel_update, which is a separate issue.
13:48 < rusty> And just because I have a large channel, doesn't mean I'm prepared to offer it to others.
13:49 < rusty> But yeah, basic idea is sound.  Blocked on fb Grand Unification.
13:50 < bitconner> #action consider removing enforcement on channel_update
13:50 < bitconner> basic idea lgtm
13:50 < bitconner> tho would probably shoot for a more specific name, e.g. option_no_funding_limit
13:50 < rusty> (Note: we don't currently enforce 2^32 limit on maximum_htlc in channel_update, this PR actually adds it, which IMHO is out of scope)
13:51 < rusty> bitconner: if only.... there were some word for this... preferably cartoon oriented...
13:51 < t-bast> :D
13:52 < bitconner> rusty: in all of our searching, wumbo is still the most descriptive
13:52 < rusty> bitconner: "wumbo"?  Never heard of it...
13:52 < bitconner> #action wumbify?
13:53 < bitconner> okie doke, gonna move on if there are no objections
13:53 < bitconner> #topic simple tooling fixes https://github.com/lightningnetwork/lightning-rfc/pull/650
13:53 < bitconner> rusty: just a clean up?
13:53 < rusty> bitconner: yeah.
13:54 < t-bast> I think for 650 the only thing I'm not a big fan of is the ...* notation
13:54 < t-bast> but that can be cleaned up later
13:54 < bitconner> cool, approved
13:54 < bitconner> t-bast: yeah it becomes less clear if there are multiple variable sized fields
13:55 < bitconner> to me n*type would allow us to express that different fields should have the same size
13:55 < rusty> bitconner: you can't have more than one in a tlv tho... that's literally the notation for "the rest of the tlv".
13:55 < bitconner> rusty: i mean that two different tlv records should have the same number of items
13:56 < t-bast> do you really want to enforce that?
13:56 < rusty> bitconner: oh... hmm, that would be nice, but hard to make a nice notation for.  Still, we can paint that bikeshed later...
13:56 < rusty> OK, so we accept this PR?
13:56 < t-bast> agreed that we can re-visit that later, ACK
13:56 < bitconner> rusty: agreed, can be something to consider down the road
13:56 < bitconner> even if we make n a keyword then it's no different from ...
13:57 < bitconner> would need to reserve a couple of single letter length variables, but something for the future :)
13:57 < rusty> bitconner: shades of Fortran!
13:57 < t-bast> we have two small ones that we discussed many times, 550 and 601
13:57 < bitconner> #agreed merge 650
13:57 < t-bast> they are very close to getting merged ;)
13:58 < bitconner> t-bast: yep i have 550 next
13:58 < bitconner> #topic define my_current_per_commitment_point https://github.com/lightningnetwork/lightning-rfc/pull/550
13:58 -!- arubi [~ese168@93-173-92-91.bb.netvision.net.il] has joined #lightning-dev
13:58 -!- arubi [~ese168@93-173-92-91.bb.netvision.net.il] has quit [Remote host closed the connection]
13:59 < bitconner> bit of recent activity on the pr itself
13:59 < bitconner> major outstanding q is to decide whether we take the lowest unrevoked point or the highest there are multiple
13:59 < niftynei> seems like comment consensus is on taking the highest
13:59 < bitconner> from the comments, it seems lnd eclair and rust-lightning all do lowest
14:00 < rusty> Yeah.... the point is that where there's ambiguity, you need to send the one you'd broadcast.  That's the *point* of sending this information, after all.
14:00 -!- arubi [~ese168@unaffiliated/ese168] has joined #lightning-dev
14:00 < t-bast> eclair does highest atm
14:00 < rusty> Sending one then broadcasting the other tx would violate the "be excellent to each other!" rule.
14:01 < bitconner> t-bast: pm47's comment says the switch happens atomically, which means eclair uses lowest iiuc
14:02 < bitconner> rusty: that's a good point
14:02 < bitconner> regarding you need to send for the one you'd broadcast
14:02 < rusty> We're atomic too; we tell the master daemon we've got the commitment, and that msg also implies permission to send the revoke_and_ack.  So if it's in the db, we have to assume we sent the revoke_and_ack.
14:02 < t-bast> bitconner: I'll get him to clarify, but I'm pretty sure we send state 1 - and we re-sent the revoke_and_ack if you didn't receive it (this is what I'm calling highest here)
14:02 < t-bast> I understood it exactly as rusty
14:03 < bitconner> got it. perhaps there's less ambiguity than i anticipated?
14:03 <+roasbeef> niftynei: there's no req to stash the "highest" though, since the other party can retransmit 
14:03 <+roasbeef> stash as in commit to disk here 
14:03 < sstone> t-bast, bitconner: yes I'm pretty sure that's what we do
14:04 <+roasbeef> this is also an area where the spec has some wiggle room 
14:04 < rusty> Strictly, you only need to remember if you sent revoke on previous, though you'd be *allowed* to, in which case your options are open to profit maximize.
14:04 < bitconner> either way, transmitting lowest or highest shouldn't cause dlp to fail
14:05 < rusty> Definitely not.  And both are tested in my protocol test PR, BTW.
14:05 < bitconner> nice
14:05 < t-bast> agreed
14:05 < niftynei> wait where are you getting stashing from roasbeef? i'm not sure i follow
14:05 -!- arubi [~ese168@unaffiliated/ese168] has quit [Quit: Leaving]
14:06 -!- arubi_ [~ese168@gateway/tor-sasl/ese168] has joined #lightning-dev
14:06 -!- arubi_ is now known as arubi
14:06 < niftynei> the requirement to retranmit is specified elsewhere i think
14:06 < rusty> niftynei: you could save the received commitment signature to the db, and not send the revoke_and_ack.  Then on restart, you can decide whether you want to have received that commitment signature or not.
14:06 < bitconner> i think he means that it's technically valid to receive a commitment and write it without actually revokeing
14:07 < t-bast> this is evil
14:07 < bitconner> don't hate the playa
14:07 < t-bast> :)
14:07 < rusty> In practice, this is dumb, since it costs you two db writes (you need another when you do send revoke_and_ack) for a very slim advantage.
14:08 < bitconner> yep, and leads to a more complex state machine
14:08 <+roasbeef> i mean that if you recv, you don't need to write it to disk
14:08 <+roasbeef> since the other party will retransmit 
14:08 <+roasbeef> but also if you _do_, the other party is actually able to send a _diff_ commit set (expired htlcs or w/e), so seems at that point y'all's state would diverge 
14:09 < rusty> roasbeef: heh... pause before sending revoke_and_ack and hope they die horribly in the meantime, then PROFIT.
14:09 <+roasbeef> or you'd just reject that even, since they're sending a diff state 5 (in this example), when you epxect 6 
14:09 < niftynei> this seems like a problem with the commitment tx exchange rather than this particular PR
14:09 < niftynei> possibly?
14:09 <+roasbeef> it's due to flexibility that's in the protocol rn 
14:09 <+roasbeef> there's 2 ways to handle this, so there's two diff points you can send 
14:10 <+roasbeef> but also if/when we move to having multuiple unrevoked, the "lowest" one is more stable, since you can have others that extend beyond 
14:11 < rusty> It's fundamental, you might have lost connectivity before receiving commitment_signed, or after sending revoke_and_ack, you don't know.  That's why we have these numbers on reestablish, though technically it could be a single bit if we wanted to optimize stupidly.
14:13 < bitconner> okay, general sentiment on 550?
14:13 < niftynei> i think that the wording on this proposed change is pretty good at encompassing either usecase "the commitment_point 
14:13 < niftynei>       corresponding to the commitment transaction the sender would use to unilaterally close"
14:13 <+roasbeef> ah would depend on if what they set there for the local/remote heights on the msg 
14:13 <+roasbeef> but it can't be ambiguous 
14:14 <+roasbeef> ppl shouldn't be able to chose, there needs to be a single correct answer, that some of us impl it differently shows that the current language is to weak also 
14:14 < niftynei> well, i mean it kind of can. either then send the 'lower' one and you assume that they, for some reason, didn't get your last message
14:14 < niftynei> or they send the 'higher' one and you know they did
14:14 <+roasbeef> i agree that "both work", but that can lead to ppl not being able to reest their channels, if from one's PoV, the other sends the wrong point  
14:14 < niftynei> either case should be covered though, no?
14:14 <+roasbeef> but with the simplified commitment stuff, the point doesn't matter, only the secret stuff 
14:15 <+roasbeef> niftynei: if they send higher and I want lower, what do I do?
14:15 < rusty> Yes, it needs to correspond to what they sent, since the receiver checks it.  Hey, did I mention I test all these cases in #655 ?
14:16 < niftynei> if you send anything other than those two points than you're definitely breaking protocol; either of them should be handle-able
14:16 < bitconner> rusty: woah nice pr
14:16 < niftynei> yeah i'm really excited about these protocol tests
14:16 < niftynei> wrt to this PR: should we change the language, accept it as is, or reject it?
14:17 <+roasbeef> (also to step back, we thought this was the issue with CL and lnd, but then it was actually just timing) 
14:17 < niftynei> i don't think it resolves the problem we've identified but it does make the spec a bit more readable imo
14:17 < niftynei> yes, correct
14:18 < niftynei> which is great! so maybe we don't need clarification and we can leave it ambiguous as is? 
14:18 -!- rusty2 [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev
14:18 -!- Emcy [~Emcy@unaffiliated/emcy] has quit [Remote host closed the connection]
14:18 < bitconner> yeah i think i'm now convinced that the current language is sufficient :)
14:19 < rusty2> Me too.  Ack!
14:19 < t-bast> sgtm then
14:19 < niftynei> great.
14:20 < bitconner> woo
14:20 < bitconner> #agreed merge using current language
14:20 -!- captjakk [~captjakk@c-65-50-169-164.hs.gigamonster.net] has quit [Ping timeout: 245 seconds]
14:21 < bitconner> we're a bit over, so probably won't get 601
14:21 <+roasbeef> rusty2: can we also get the original rusty to confirm as well?
14:21 < bitconner> unless anyone has a burning issue
14:21 < t-bast> very quickly on 627: do you feel this new error code is needed or should I just retract this PR and use the general PERM error?
14:21 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 272 seconds]
14:21 < t-bast> I'm just curious what your implementations do (they have to somehow handle that code-path)
14:22 < t-bast> roasbeef: agreed, I don't know who that rusty2 guy is
14:22 <+roasbeef> it's more forward looking imo, we'll need it in the future as the payload get more flexible 
14:22 -!- rusty2 is now known as rusty
14:22 <+roasbeef> but rn, not like yo ucan fail to decode an integer, since it's all fixed sized 
14:22 < rusty> roasbeef: done :)
14:22 <+roasbeef> btu when we have a buncha types in there, makes sense to be able to say "actually idk what this is"
14:23 < bitconner> t-bast: yeah i think it'll be useful for tlv payloads, i'd keep it open
14:23 < t-bast> ok great, let's discuss on the PR then since we're overtime
14:23 < bitconner> sgtm
14:23 < bitconner> #endmeeting
14:23 < lightningbot> Meeting ended Mon Aug  5 21:23:42 2019 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
14:23 < lightningbot> Minutes:        http://www.erisian.com.au/meetbot/lightning-dev/2019/lightning-dev.2019-08-05-20.03.html
14:23 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/lightning-dev/2019/lightning-dev.2019-08-05-20.03.txt
14:23 < lightningbot> Log:            http://www.erisian.com.au/meetbot/lightning-dev/2019/lightning-dev.2019-08-05-20.03.log.html
14:23 < rusty> ack, thanks.
14:23 < bitconner> thanks everyone!
14:23 < niftynei> thanks bitconner !!
14:24 < bitconner> we have a few prs to merge 🎉
14:24 < t-bast> thanks everyone and thanks to our democratically-elected chair ;)
14:24 < niftynei> do we have a volunteer to chair next meeting?
14:24 < bitconner> the iron throne is quite comfy i must say
14:24 < t-bast> I can chair next time if you want
14:24 < cdecker> Thanks bitconner for chairing :-)
14:25 < t-bast> Or we can give the chair back to the OGs (cdecker, rusty, roasbeef)
14:26 < niftynei> fwiw i second the t-bast nomination :)  
14:27 < t-bast> so I'm democratically elected with 2 voices and a low turnout, sounds like french elections I like it 
14:27 < bitconner> lolol
14:27 < bitconner> t-bast4prez
14:28 < bitconner> tune in 2 weeks for the inauguration
14:28 < t-bast> hell yeah
14:28 < t-bast> gonna rain champagne
14:28 < t-bast> see you guys, good morning/day/night
14:29 -!- t-bast [~t-bast@2a01:e34:ec2c:260:510e:a6d0:4632:adce] has quit [Quit: Leaving]
14:29 < niftynei> tchau!
14:31 -!- mdunnio [~mdunnio@38.126.31.226] has quit [Remote host closed the connection]
14:32 < sstone> bye everyone!
14:32 -!- sstone [~sstone@185.186.24.109.rev.sfr.net] has quit [Quit: Leaving]
14:33 < cdecker> See you ^^
14:38 -!- ccdle12 [~ccdle12@cpc139350-aztw33-2-0-cust310.18-1.cable.virginm.net] has quit []
14:45 -!- mdunnio [~mdunnio@38.126.31.226] has joined #lightning-dev
14:45 -!- ccdle12 [~ccdle12@cpc139350-aztw33-2-0-cust310.18-1.cable.virginm.net] has joined #lightning-dev
14:47 -!- __gotcha [~Thunderbi@plone/gotcha] has joined #lightning-dev
14:48 -!- captjakk [~captjakk@c-65-50-169-164.hs.gigamonster.net] has joined #lightning-dev
14:49 -!- ccdle12 [~ccdle12@cpc139350-aztw33-2-0-cust310.18-1.cable.virginm.net] has quit [Client Quit]
14:58 -!- ccdle12 [~ccdle12@cpc139350-aztw33-2-0-cust310.18-1.cable.virginm.net] has joined #lightning-dev
15:02 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 268 seconds]
15:04 -!- captjakk [~captjakk@c-65-50-169-164.hs.gigamonster.net] has quit [Ping timeout: 258 seconds]
15:08 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.]
15:10 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Ping timeout: 245 seconds]
15:11 -!- Emcy [~Emcy@200.177.9.51.dyn.plus.net] has joined #lightning-dev
15:11 -!- Emcy [~Emcy@200.177.9.51.dyn.plus.net] has quit [Changing host]
15:11 -!- Emcy [~Emcy@unaffiliated/emcy] has joined #lightning-dev
15:14 -!- mdunnio [~mdunnio@38.126.31.226] has quit [Remote host closed the connection]
15:14 -!- hiroki_ [cad6a796@150.167.214.202.rev.vmobile.jp] has quit [Remote host closed the connection]
15:17 -!- Emcy [~Emcy@unaffiliated/emcy] has quit [Quit: Leaving]
15:18 -!- Emcy [~Emcy@unaffiliated/emcy] has joined #lightning-dev
15:18 -!- Emcy [~Emcy@unaffiliated/emcy] has quit [Remote host closed the connection]
15:19 -!- Emcy [~Emcy@unaffiliated/emcy] has joined #lightning-dev
15:26 -!- ccdle12 [~ccdle12@cpc139350-aztw33-2-0-cust310.18-1.cable.virginm.net] has quit []
15:34 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood]
15:35 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #lightning-dev
15:41 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood]
15:42 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #lightning-dev
15:52 -!- melvster [~melvin@ip-86-49-18-190.net.upcbroadband.cz] has quit [Ping timeout: 246 seconds]
16:02 -!- captjakk [~captjakk@75-166-173-191.hlrn.qwest.net] has joined #lightning-dev
16:16 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #lightning-dev
16:29 -!- laptop500 [~laptop@host81-147-158-108.range81-147.btcentralplus.com] has quit [Ping timeout: 248 seconds]
17:05 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev
17:11 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 246 seconds]
17:12 < rusty> So, the problem with the bolt11 nonce is it's trivially vulnerable to a downgrade attack.  So I'm pushing bolt11 feature bits, so we can get everyone to upgrade ASAP, then we can have a planned transition to making the nonce compulsory for unspecified-value invoices.
17:19 < bitconner> what sort of downgrade attack?
17:19 < bitconner> we shouldn't be promoting zero-value invoices anyway, so the latter isn't a concern for me
17:19 < bitconner> (in reality, we should begin phasing them out)
17:25 -!- riclas [riclas@77.7.37.188.rev.vodafone.pt] has quit [Ping timeout: 268 seconds]
17:26 -!- tryphe_ is now known as tryphe
17:28 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #lightning-dev
17:31 < rusty> bitconner: if they're not required, the attacker doesn't use them, and attack still works.
17:32 < rusty> bitconner: why would we phase them out?
17:33 < bitconner> rusty: who is the attacker in this case? someone other than sender or receiver?
17:34 < rusty> bitconner: intermediate node guesses target, tries paying 1 msat, gets preimage, takes funds.
17:34 < rusty> This is possible with any overpaying, but it's worse with any-value-accepted invoices.
17:35 < rusty> Hence the idea of adding a nonce in the invoice that they have to use in the onion.  However, if it's optional, it's useless.
17:35 < bitconner> gotcha, yeah there would be a transitionary period where that would work, unless the receiver also mandates it when actually receiving. unupgraded senders would just get a payment failure
17:36 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #lightning-dev
17:36 < bitconner> either way tho there will be this period, since its already possible today if we do nothing
17:37 < rusty> bitconner: yeah, since we're adding feature bits to bolt11 (should have done from day 1, but I'm learning!) we can also transition so they'll fail at that stage (even bit) which is far more informative.
17:37 < bitconner> "why would we phase them out" because they're in secure, and we have better ways of doing donation invoices where the onion commits to the final value
17:37 < rusty> bitconner: NO NO NO.  That's horribly broken.
17:37 < rusty> bitconner: paying without an invoice a terrible step backwards.
17:38 < rusty> bitconner: the real solution is to have an inband way of requesting a fresh invoice.
17:38 < rusty> Which solves this problem and so many others (recurring payments) without throwing payments into the wind and trusting that the vendor will honor them.
17:39 < bitconner> i don't follow how that's broken, but it covers one use-case supported by zero-value invoices
17:39 < rusty> bitconner: It's not worse than zero value invoices, but it's less secure for anything else.
17:40 < rusty> But we should be aiming to bring "donations" up to the same proof level as other paymets.
17:40 < rusty> Sigh.  bitconner I think you've just convinced me I need to work on inline invoice requests.  A big task though...
17:41 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 245 seconds]
17:41 < bitconner> the sender has to communicate the amount to the receiver at some point. either it's done in the onion (e2e authenticated) or during invoice generation via some out of band authentication mechanism. not having a value in the invoice and not committing to the total amount being paid is where the issue lies
17:42 < bitconner> not everything needs an invoice or requires the same level of proof
17:42 < rusty> bitconner: true.  The bolt11 offer proposal solves this as well as things like recurring payments, multi pay and static "invoices".  But, needs to  be written up and implemente.
17:42 < bitconner> having the preimage is functionally equivalent to a db entry that says "i paid"
17:43 < rusty> bitconner: not everything needs encryption, but it's not optional in the spec for good reason!
17:44 < rusty> bitconner: not at all.  I can prove that the invoice was paid, and that's extremely important in cases of dispute (proof that *I* paid would be better, but see Scriptless Scripts).  This is hard to extrapolate from current usage, but when you think about finance without intermediaries, the requirement becomes clearer.
17:45 < bitconner> you want that for large payments, but is a court going to hear out my case for 1 msat?
17:47 < rusty> bitconner: no, first you go to the vendor and say 'hey, I paid, what's happening?'.  You prove it was paid, now it's up to them to argue (and maybe fix their broken system).  If not, you use social means aka Twitter to demonstrate they didn't honor the payment.
17:48 < rusty> This is the difference between Lightning for real commerce, and Lightning today where we're all friendsa.
17:49 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #lightning-dev
17:52 < bitconner> sure but that can be up to users if they want that ability. you suspect a merchant is shady, spread the word to get real invoices, wait till it happens again. it isn't a critical component of the payment flow, tho there are plenty of cases where it does offer utility
17:53 < rusty> bitconner: This whole attitude is completely wrong.  You don't downgrade security for cases where it's not necessary.  You design for the best security you can, then apply it universally.
17:53 < bitconner> i think we're getting off track tho. the main point re: zero-value invoices is that the sender should ask for an invoice with the amount they want to send
17:54 < bitconner> rusty: it's not any less secure. it only matters for handling out-of-band resolution
17:55 < rusty> bitconner: too narrow a definition of secure, IMHO.
17:55 < bitconner> "You design for the best security you can, then apply it universally." i assure we share the same beliefs here
17:55 < rusty> The protocol worked, but the vendor stole my money.
17:56 < bitconner> the receiver stole my donation, oh no!
17:57 < rusty> bitconner: except that Eclair defaults to amountless invoices.  I assure you, they're not just being used for donations.
17:57 < rusty> (Eclair mobile).
17:58 < bitconner> that's.. not the best idea
17:58 <+roasbeef> rusty: i don't get the downgrade, the receiver would still just reject if it wasn't included 
17:59 < rusty> roasbeef: yes, if it's compulsory.  But that's a hard transition to make.
17:59 <+roasbeef> yeh, until the receiver (who is generating the invoices has upgraded), they aren't protected, unless they validate the amount to the sender out of band 
18:00 < rusty> roasbeef: which has me speculating that we'd be better off doing this bolt11 offer idea...
18:00 < rusty> y'know, since we're all sitting around bored with nothing to work on.
18:01 <+roasbeef> why isn't just adding a tag enough? if it's there, include it, done, simple 
18:01 <+roasbeef> > 20:23 < rusty> bitconner: the real solution is to have an inband way of requesting a fresh invoice.
18:01  * roasbeef whispers HORNET... 
18:01 < rusty> roasbeef: That joke never gets old :)
18:02 <+roasbeef> also the "prove I paid" requires cooperation from the receiver, so in that model, you can do the same with "I paid, you should have the pre-image now" 
18:02 <+roasbeef> since there's no binding at the sender yet 
18:04 <+roasbeef> re eclair: are we sure about this? then their receivers have no guarantee at all? in their recv hooks do they provide the value? 
18:04 < bitconner> with regards to donation invoices, what exactly does an invoice do for you? i have the preimage and an invoice, but all i can prove is that i sent 0 sats
18:05 < rusty> roasbeef: Yeah, I have Eclair on my phone.  Default invoice doesn't have an amount attached.
18:06 < rusty> bitconner: indeed, it's a hole, though that pay still be helpful in the case where there's confusion, not malice.  We should do better, and I think we should.
18:07 < bitconner> it's all kinda moot since we will have the best of both worlds eventually
18:07 <+roasbeef> ok, they should really fix that then, seems users would be confused even before anything nefarious happened 
18:07 < rusty> roasbeef: but typing amounts on mobile is a PITA.
18:07 <+roasbeef> yeh...include it in the invoice lol
18:08 < bitconner> one of the two parties has to type it...
18:08 < bitconner> speach to text ftw
18:08 < rusty> bitconner: sure, which is why I'm leaning towards the End Goal, which gets us to Invoice Nirvana.
18:08 -!- captjakk [~captjakk@75-166-173-191.hlrn.qwest.net] has quit [Remote host closed the connection]
18:09 <+roasbeef> but yeh HORNET would allow you to request an arbitrary amount of invoices, exchange sigs for auth, etc, etc 
18:09 <+roasbeef> rusty: so you don't think that just adding the tag is enough? (to re-focus) 
18:09 <+roasbeef> assuming we need the receiver to update (since it's a reciver issue) 
18:10 < rusty> roasbeef: since proof of payment is so weak anyway, perhaps we're best off deprecating unamounted and using the preimage-in-onion-secret trick?
18:10 <+roasbeef> depracating would be a bigger thing ecosystem wide, given that eclair is already using it by default and a lot of other serivces are 
18:11 < bitconner> rusty: or just having the receiver include the amount when generating the invoice, that is the alternative fix
18:11 <+roasbeef> we can do a gradual roll out with the tag: if it's there and you know what it is, include it 
18:11 < rusty> I'm trying to think what easiest transition is.
18:11 <+roasbeef> yeh i don't think there's a very easy way, at this stage, ppll have stopped making them, but some still default 
18:11 <+roasbeef> it'll be gradual  if we add the tag, then let those that rely on it critically to update 
18:11 < bitconner> (also the latter fix can be deployed today w/o waiting for protocol improvements)
18:11 <+roasbeef> fwiw, people are already used to that flow, and some services are now built around it 
18:12 <+roasbeef> yeah we can add a tag _today_, and begin the roll out 
18:12 <+roasbeef> (assuming a tlv onion aware sender and receiver) 
18:12 < rusty> roasbeef: yeah, I was going for: bolt11 feature bits ASAP.  Then nonce tag (`8` FWIW), plus assign feature bits.  That way you can indicate it's compulsory at handwave some future point.
18:12 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #lightning-dev
18:13 <+roasbeef> do we need the bits? can't we just check the invoice to see if the tag is there? 
18:13 < rusty> roasbeef: well, if we'd had feature bits initially, this would be trivial.  Spec says ignore unknown tags, but feature bit spec says fail on unknown even, so you'd get a nice message as a user if you didn't support.
18:14 -!- Kostenko [~Kostenko@195.12.50.233] has quit [Ping timeout: 245 seconds]
18:14 < bitconner> rusty: i think we can skip the feature bit step and just start enforcing the tag on the receiver side. doesn't that save a round of coordination?
18:14 < rusty> roasbeef: yes, you should use nonce if available, but that also requires transition to TLV onion (depending on how we encode nonce?) so might not be both.
18:14 < rusty> bitconner: worse UX in the fail case though.
18:14 <+roasbeef> yeh, there's no good way to address w/o stuff in the onion
18:15 < rusty> We have bolt11 feature proposal ready to go (part of base amp), I've just extracted that into its own PR
18:15 < rusty> https://github.com/lightningnetwork/lightning-rfc/pull/656
18:15 <+roasbeef> either way, this'll be a multi-step thing to get ppl upgraded, no quick easy path unfortunately :( 
18:16 <+roasbeef> only current step is awareness, and some wallets like Zap have blog posts saying why they don't allow them atm 
18:16 < rusty> If you two give me a soft ack I'm happy to deploy that today into c-lightning for this coming release, so at least we'll know if future invoices require nonce and we don't support yet.
18:16 <+roasbeef> some wallets were also never able to send to them, since you needed to input a value on like mobile or w/e 
18:16 < rusty> roasbeef: this is why we're paid the big bucks, I guess.
18:17  * roasbeef pulls up pants 
18:17 < rusty> (At least, I'
18:17 < rusty> m assuming we will be, y'know, reimbuirsed by the Bitcoin Cabal.  Surely they're just waiting for wumbo support...
18:18 < bitconner> rusty: just the nonce, or the feature bit approach?
18:19 < rusty> bitconner: if I put in support for the bolt11 feature bit now, we can use it for upgrades from now on.  Including nonce; we can later assign a bit to make it break older clients.
18:20 < rusty> (the problem being that existing implementations ignore the `9` field, so won't get upset at even bits there)
18:21 < rusty> It's trivial to implement (though check my test vectors please!)
18:21 < rusty> t-bast loves implementing this stuff, but he's asleep.
18:22 <+roasbeef> ok i think i understand the UX argument for having the feature bit there now 
18:22 < rusty> Stronger argument for going back in time and implementing it, but yeah.
18:23 < bitconner> okay roasbeef explained the ux improvement to me, ack from me
18:23 < rusty> bitconner: anyone want to implement it so you can soft-ack pending next mtg?
18:24 < bitconner> i will talk to my operatives and see to it
18:26 < rusty> bitconner: "operatives", I like it.  Apparently my underlings take objection to being called lackeys!
18:27 -!- Kostenko [~Kostenko@195.12.50.233] has joined #lightning-dev
18:51 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Read error: Connection reset by peer]
18:52 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev
18:58 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 268 seconds]
19:05 < rusty> roasbeef: https://github.com/lightningnetwork/lightning-rfc/pull/571 can we just go with bitconner's "node" and "connection" feature names?  I'm getting nomenclature whiplash!
19:13 -!- Kostenko [~Kostenko@195.12.50.233] has quit [Ping timeout: 245 seconds]
19:28 -!- Kostenko [~Kostenko@2001:8a0:729c:8201:1aa9:7fc2:2111:f256] has joined #lightning-dev
21:31 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Ping timeout: 260 seconds]
21:45 -!- kam270 [~kam270@183.182.104.69] has joined #lightning-dev
22:07 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
23:05 -!- melvster [~melvin@ip-86-49-18-190.net.upcbroadband.cz] has joined #lightning-dev
23:46 -!- jungly [~quassel@79.8.200.97] has joined #lightning-dev
--- Log closed Tue Aug 06 00:00:31 2019