--- Log opened Mon Aug 19 00:00:49 2019
00:01 -!- mauz555 [~mauz555@2a01:e35:8ab1:dea0:6590:27a1:bba0:f646] has joined #lightning-dev
00:05 -!- mauz555 [~mauz555@2a01:e35:8ab1:dea0:6590:27a1:bba0:f646] has quit [Ping timeout: 250 seconds]
00:12 -!- queip [~queip@unaffiliated/rezurus] has joined #lightning-dev
00:22 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 244 seconds]
00:40 -!- jungly [~quassel@79.8.200.97] has joined #lightning-dev
00:52 -!- queip [~queip@unaffiliated/rezurus] has joined #lightning-dev
00:59 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 248 seconds]
01:01 -!- mauz555 [~mauz555@2a01:e35:8ab1:dea0:6590:27a1:bba0:f646] has joined #lightning-dev
01:15 -!- queip [~queip@unaffiliated/rezurus] has joined #lightning-dev
01:22 -!- mauz555 [~mauz555@2a01:e35:8ab1:dea0:6590:27a1:bba0:f646] has quit [Remote host closed the connection]
01:23 -!- mauz555 [~mauz555@2a01:e35:8ab1:dea0:6590:27a1:bba0:f646] has joined #lightning-dev
01:26 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 248 seconds]
01:36 -!- noxx [~noxx@p200300E617041900ECFC487010BBEBDA.dip0.t-ipconnect.de] has quit [Quit: Leaving]
01:38 -!- queip [~queip@unaffiliated/rezurus] has joined #lightning-dev
01:46 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 268 seconds]
01:50 -!- enemabandit [~enemaband@185.227.37.188.rev.vodafone.pt] has joined #lightning-dev
01:50 -!- enemabandit [~enemaband@185.227.37.188.rev.vodafone.pt] has quit [Client Quit]
02:33 -!- riclas [~riclas@77.7.37.188.rev.vodafone.pt] has joined #lightning-dev
02:33 -!- melvster [~melvin@ip-86-49-18-190.net.upcbroadband.cz] has quit [Read error: Connection reset by peer]
02:33 -!- melvster [~melvin@ip-86-49-18-190.net.upcbroadband.cz] has joined #lightning-dev
02:36 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 272 seconds]
02:43 -!- reallll is now known as belcher
02:43 -!- queip [~queip@unaffiliated/rezurus] has joined #lightning-dev
02:55 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 248 seconds]
02:56 -!- mauz555 [~mauz555@2a01:e35:8ab1:dea0:6590:27a1:bba0:f646] has quit [Remote host closed the connection]
02:57 -!- tombusby [~tombusby@gateway/tor-sasl/tombusby] has quit [Ping timeout: 260 seconds]
03:04 -!- rh0nj [~rh0nj@88.99.167.175] has quit [Remote host closed the connection]
03:05 -!- rh0nj [~rh0nj@88.99.167.175] has joined #lightning-dev
03:07 -!- tombusby [~tombusby@gateway/tor-sasl/tombusby] has joined #lightning-dev
03:08 -!- queip [~queip@unaffiliated/rezurus] has joined #lightning-dev
03:15 -!- mauz555 [~mauz555@2a01:e35:8ab1:dea0:6590:27a1:bba0:f646] has joined #lightning-dev
03:19 -!- marcoagner [~user@2001:8a0:6a53:2e00:1967:22be:ad77:2d5] has joined #lightning-dev
03:19 -!- marcoagner [~user@2001:8a0:6a53:2e00:1967:22be:ad77:2d5] has quit [Client Quit]
03:19 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 246 seconds]
03:20 -!- marcoagner [~user@2001:8a0:6a53:2e00:1967:22be:ad77:2d5] has joined #lightning-dev
03:24 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev
03:42 -!- Kostenko [~Kostenko@dsl-155-30.bl26.telepac.pt] has joined #lightning-dev
03:54 -!- Kostenko [~Kostenko@dsl-155-30.bl26.telepac.pt] has quit [Ping timeout: 268 seconds]
04:07 -!- Kostenko [~Kostenko@195.12.50.233] has joined #lightning-dev
04:31 -!- noxx [~noxx@p200300E61704190098E8C6008F381C13.dip0.t-ipconnect.de] has joined #lightning-dev
04:36 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #lightning-dev
04:54 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 246 seconds]
04:55 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #lightning-dev
05:05 -!- noxx [~noxx@p200300E61704190098E8C6008F381C13.dip0.t-ipconnect.de] has quit [Quit: Leaving]
05:29 -!- sfhi [~sfhi@178.255.154.107] has joined #lightning-dev
05:31 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 246 seconds]
05:40 -!- queip [~queip@unaffiliated/rezurus] has joined #lightning-dev
06:03 -!- tombusby [~tombusby@gateway/tor-sasl/tombusby] has quit [Remote host closed the connection]
06:06 -!- tombusby [~tombusby@gateway/tor-sasl/tombusby] has joined #lightning-dev
07:33 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 258 seconds]
07:44 -!- queip [~queip@unaffiliated/rezurus] has joined #lightning-dev
08:04 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 248 seconds]
08:15 -!- queip [~queip@unaffiliated/rezurus] has joined #lightning-dev
08:17 -!- Amperture [~amp@24.136.5.183] has quit [Ping timeout: 272 seconds]
08:39 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 272 seconds]
08:43 -!- mauz555 [~mauz555@2a01:e35:8ab1:dea0:6590:27a1:bba0:f646] has quit [Remote host closed the connection]
08:53 -!- queip [~queip@unaffiliated/rezurus] has joined #lightning-dev
09:22 -!- mauz555 [~mauz555@bny93-8-88-171-29-234.fbx.proxad.net] has joined #lightning-dev
09:45 -!- joostjgr [~joostjag@ip51cf95f6.direct-adsl.nl] has joined #lightning-dev
09:46 -!- joostjgr [~joostjag@ip51cf95f6.direct-adsl.nl] has quit [Client Quit]
09:52 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 245 seconds]
10:04 -!- queip [~queip@unaffiliated/rezurus] has joined #lightning-dev
10:06 -!- mauz555 [~mauz555@bny93-8-88-171-29-234.fbx.proxad.net] has quit []
10:12 -!- joostjgr [~joostjag@ip51cf95f6.direct-adsl.nl] has joined #lightning-dev
10:26 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 245 seconds]
10:26 -!- joostjager [~joostjgr@ip51cf95f6.direct-adsl.nl] has joined #lightning-dev
10:43 -!- queip [~queip@unaffiliated/rezurus] has joined #lightning-dev
11:12 -!- noxx [~noxx@p200300E617041900017FC2D0B77723AF.dip0.t-ipconnect.de] has joined #lightning-dev
11:12 -!- noxx [~noxx@p200300E617041900017FC2D0B77723AF.dip0.t-ipconnect.de] has quit [Remote host closed the connection]
12:20 -!- reallll [~belcher@unaffiliated/belcher] has joined #lightning-dev
12:24 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 272 seconds]
12:33 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 246 seconds]
12:42 -!- queip [~queip@unaffiliated/rezurus] has joined #lightning-dev
12:42 -!- hiroki_ [a331cc5f@95.204.49.163.rev.vmobile.jp] has joined #lightning-dev
12:47 -!- t-bast [~t-bast@2a01:e34:ec2c:260:b05f:4b89:740:1fce] has joined #lightning-dev
12:55 -!- sstone [~sstone@li1491-181.members.linode.com] has joined #lightning-dev
12:56 -!- ysangkok [janus@hapy.0x90.dk] has joined #lightning-dev
12:59 < rusty> Hi all!
13:00 < niftynei> hellllllo
13:00 < t-bast> Hey all
13:00 < sstone> Hi!
13:01 < t-bast> is LL in da place? @bitconner @roasbeef?
13:01 -!- sfhi [~sfhi@178.255.154.107] has quit [Quit: Leaving]
13:01 < cdecker> Hi everybody
13:02 -!- melvster [~melvin@ip-86-49-18-190.net.upcbroadband.cz] has quit [Remote host closed the connection]
13:02 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 258 seconds]
13:04 -!- melvster [~melvin@ip-86-49-18-190.net.upcbroadband.cz] has joined #lightning-dev
13:04 < BlueMatt> yoyoyo
13:05 < sstone> hi Matt long time no see :)
13:05 < BlueMatt> lolikr
13:05 < BlueMatt> well timezone means my calendar entry was wrong
13:05 < t-bast> :)
13:05 < BlueMatt> someone should create a gcal object that everyone can add like there is for -core-dev
13:06 < t-bast> or maybe the meeting time should be indexed on a specific block height?
13:06 < t-bast> I think we have a gcal object don't we?
13:07 < rusty> t-bast: there is one... I can add...
13:07 < cdecker> We do, but I don't think it's publicly subscribable
13:07 < t-bast> got it
13:08 < t-bast> does some have eyes in SF to spot bitconner or roasbeef?
13:08 < t-bast> *someone
13:08 < rusty> Invite sent to BlueMatt....
13:09  * rusty wonders how to make it a public thing somehow...
13:09 < BlueMatt> lol, via what email, I've only got like 500 of them
13:10 <+roasbeef> i think we just all have our own calender entries?
13:10 < cdecker> You clearly need a mail that notifies you of mail in other mailboxes
13:10 < t-bast> shall we start? Am I still very democratically elected to chair today?
13:10 < BlueMatt> cdecker: that I do have, but as it turns out push email across 40 folders on thunderbird (and, really, everywhere) sucks :'(
13:10 < BlueMatt> anyway, lets start
13:11 < cdecker> roasbeef: I see no-one else jumping at the opportunity :-)
13:11 <+roasbeef> #startmeeting
13:11 < lightningbot> Meeting started Mon Aug 19 20:11:44 2019 UTC.  The chair is roasbeef. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:11 < lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
13:11 <+roasbeef> will go down le list in order 
13:12 < t-bast> Is there a reason why 608 wasn't merged? We had an action item to merge it last time.
13:12 <+roasbeef> #topic #658 and #643 (mpp and amp drafts) 
13:12 <+roasbeef> say no more t-bast 
13:13 < t-bast> neat, the merging machine is on
13:13 <+roasbeef> ok in these two, conner recently put up the draft of the secret sharing spontaenous variant 
13:13 < cdecker> #643 needs a rebase now that #619 was merged
13:13 -!- queip [~queip@unaffiliated/rezurus] has joined #lightning-dev
13:13 <+roasbeef> thinking that there's a goodo bit over overlap between this an the invoice based on 
13:13 < cdecker> Shall I quickly do that?
13:13 <+roasbeef> for example, they may share some TLV keys (the strem_id) field for example 
13:14 <+roasbeef> cdecker: rebase it? 
13:14 < cdecker> roasbeef: yes :-)
13:14 < t-bast> I think the main difference is that #658 adds the spontaneous part: both are atomic (in a way, one has atomicity controlled by the sender, the other by the recipient)
13:14 < t-bast> I would see #658 as an addition to #643
13:15 <+roasbeef> heh "atomic", but let's not get caught up on wording 
13:15 < t-bast> (by the way there are many open comments on both PRs, interesting discussions there)
13:15 < cdecker> Sender controlled atomicity is a red herring if you ask me
13:15 < t-bast> depends on the context, in #658 it kinda makes sense
13:16 <+roasbeef> we may even just merge them into a single PR possibly, since there's so much overlap 
13:16 <+roasbeef> both needs a feature bit global, invoice tags, etc 
13:16 < t-bast> roasbeef: that would be a good idea to make it easy to digest as a whole, but implementation can really be done in several independent steps imo
13:17 < t-bast> rusty's MPP doesn't need a global feature bit as it's invoice-driven (the feature bit is inside the invoice)
13:17 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 245 seconds]
13:17 < t-bast> unless we want to allow receiving invoice-less payments through rusty's proposal, but for invoice-less payments I think #658 makes more sense
13:18 < cdecker> I don't think that putting both proposals in a single PR is a good idea (I for one am not sold on the idea of #658)
13:18 < t-bast> Can you explain what you don't like in #658?
13:18 < rusty> I think #658 is eventually obsoleted by Schnorr and bolt 11 offers, but that's a long enough lifetime to be useful IMHO.
13:19 <+roasbeef> obsolted by schnorr, maybe in 2 years 
13:19 < bitconner> both are obsoleted by schnorr
13:19 <+roasbeef> even then you can apply the same derivation to make it work with schnorr 
13:20 <+roasbeef> tons of devs are begging for the spontaneous payment feature,so would be curious what your qualms are decker 
13:20 <+roasbeef> there's even a cut out for re-occuring payments now 
13:20 <+roasbeef> and many exchange favor that model over invoices, since if re-used they can be dangerous 
13:20 < rusty> roasbeef: well, bolt11 offers are a superior way of doing this and getting a receipt.  
13:21 < cdecker> How is base-amp obsoleted by schnorr?
13:21 < cdecker> The idea is still sound: have the recipient trigger the settlement of all parts, and communicate the total amount in the onion
13:21 <+roasbeef> ofc there are trade offs rusty, in some cases the "receipt" is less critical, and a slighlty weaker proof of payment is possilbe
13:21 < t-bast> rusty: could you share what you mean by Bolt11 offers? I haven't heard of that before
13:21 < bitconner> you can have parial payment decorrelation and pop
13:21 <+roasbeef> in the end it falls back to disputes with the sender/receiver which are all extra protocol
13:22 <+roasbeef> i think we means the feature bits in bolt 11? (another PR) 
13:22 < BlueMatt> right, but non-base amp makes sense for spontaneous payments, base amp keeps the same properties people are used to today
13:22 < BlueMatt> I dunno why we have to decide between one or the other, combine them as much as possible and realize they're both useful
13:22 < bitconner> ^^
13:23 < t-bast> I agree with BlueMatt there, I think base-amp is simple enough to implement and spec, and can be enriched with the spontaneous part afterwards with bitconner's proposal
13:23 < rusty> t-bast: https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-November/001602.html
13:23 < t-bast> thx
13:23 < BlueMatt> ux messaging is hard, but imo makes sense to use base amp where possible if you have an invoice and original amp if you want spontaneous payment
13:23 < BlueMatt> obviously with schnorr once we get there
13:23 < cdecker> BlueMatt: we can have spontaneous payments for free if we use the shared secret from the onion, no need for anything more complex than the hash functions we already use
13:24 < cdecker> And the shared secret preimage trick works great in conjunction with base-amp
13:24 < BlueMatt> right, fair, but might as well combine in a useful way with amp, is my point
13:24 < BlueMatt> ie if you want amp over spontaneous payments, might as well do it this way
13:25 < bitconner> cdecker: tho cool, i'm not sure it's worth adding yet another payment mechanism when one is a generalization of the other
13:26 < t-bast> rusty, cdecker, is your concern mostly because you'd like spontaneous payments to have a proof-of-payment, which Bolt11 offers can provide and #658 can't provide?
13:27 < cdecker> t-bast: spontaneous payments do not have a proof by definition (until we get schnorr)
13:27 < cdecker> My objection is that #658 doesn't add much if we have two simpler mechanisms already
13:27 < t-bast> cdecker: but the proposal linked by rusty does provide a pop - it's not fully spontaneous though, but probably spontaneous enough?
13:28 < rusty> t-bast: can't speak for cdecker, but I feel strongly that in a cash-like system without an intermediary, receipts have proven themselves throughout history to be a vital protection.  It's more work to spec up, but it's where we want to end up IMHO.
13:28 < bitconner> cdecker: how does schnorr enable pop for spontaneous payments?
13:28 < t-bast> rusty: got it, thanks for clarifying
13:28 < BlueMatt> cdecker: ah, wait, am I misunderstanding (sorry, I havent been as active recently, so feel free to tell me to fuck off), but is there a way to do spontaneous payments over BAMP?
13:28 < rusty> I'm not sure if the layering violation of using the onion to hold the spontaneous secrets is worthwhile.
13:29 < t-bast> Maybe it would be worth drafting a formal proposal using the onion shared secret preimage trick to compare to #658?
13:29 < BlueMatt> cause spontaneous payments over BAMP seems like a nice thing to me
13:29 <+roasbeef> BlueMatt: +1 on combine they serve diff needs 
13:29 -!- queip [~queip@unaffiliated/rezurus] has joined #lightning-dev
13:30 <+roasbeef> cdecker: xor is pretty basic, even less complex that hash functions ;), the shared secret approach is nice, but possible consumders i've talked to for this feature find it lacking and want more structured information at the other end 
13:30 < cdecker> BlueMatt: yes, there is a way to do spont payments over base-amp (sender encodes the preimage in the shared secret for the onion, and then we deterministically generate from there)
13:30 < BlueMatt> ah, right
13:30 < BlueMatt> welllllll
13:31 <+roasbeef> better to have a unified way to do spont payments that 3 methods, that case is just amp with a payment shard size of 1 
13:31 < cdecker> Unless you try to generate preimages in a certain format (common prefix or something), which I'd strongly discourage, there is absolutely no downside to using the shared secret there
13:31 <+roasbeef> but feels liek we're getting off track here, what do people think of combining them (PR wise) since ther's so much over lap 
13:31 < cdecker> NACK
13:31 <+roasbeef> you're limited in what secret you can pick cdecker, since it depend son their pubkey 
13:32 <+roasbeef> "no down side", it leaks layers, and doesn't provide any additional structure 
13:32 < cdecker> But you should be picking it randomly anyway, and it is the result of an ECDH that you executed with a random secret you generated yourself
13:32 <+roasbeef> sure they shoudl be random, but also cuould be derived off soem other sub-protocol 
13:33 < cdecker> There is no additional structure, but I'll give you the layering violation :-)
13:33 <+roasbeef> that case is a sub-set of the greater amp scheme, since it's a single payment vs many others 
13:33 < rusty> TBH I share roasbeef's dislike of the layering violation.
13:33 < t-bast> +1 on the layering violation, it feels a bit hackish
13:33 <+roasbeef> it's a cool trick, but we have a way to encompass that use case, and provide additional utility with the greater amp proposal
13:33  * cdecker reluctantly agrees that the layering violation is bad
13:35 < t-bast> I'm afraid that sharing the PR would slow us down. It seems like #658 can easily build on top of #643, wdyt?
13:36 <+roasbeef> are there major blockers with either of them? 
13:36 < cdecker> Agreed
13:36 < rusty> I rather like the XOR proposal.  It's nice because it genuinely decorrelates the separate paths.  It also uses our shiny new onion format FTW.  I agree with bitconner that there's a large amount of overlap, so #643 should be generalized (make sure terminology is OK) so it's easy to add #658.
13:37 < t-bast> No major blocker from my point of view, a lot of interesting discussion have already started on the PRs themselves, we should keep them active on Github.
13:38 < bitconner> agree on keeping both as separate proposals, i tried to base 658 on 643 as far as requirements so that feedback can easily be shared between the two
13:38 < bitconner> :)
13:39 <+roasbeef> ok, so move on there and keep the dicsussion in github
13:39 <+roasbeef> ? 
13:39 < bitconner> sgtm
13:39 < t-bast> So next steps: rebase #643 on master, make progress on comments and rebase #658 on #643?
13:39 <+roasbeef> #action rebase #643 on master, continue discussion of #658 and #643 on github, to bubble up in the meeting as needed 
13:40 < t-bast> ACK
13:40 < rusty> (Assume there's an implied "rusty" in that rebase... will do :)
13:40 <+roasbeef> #topic 657
13:40 < t-bast> heh
13:40 <+roasbeef> (channel_update after exchange funding_locked) 
13:41 < t-bast> there are a few distinct PRs that bubble up issues with channel establishment messages (657, 620 and 625)
13:41 < t-bast> it would be nice to clear these up
13:42 <+roasbeef> so seems to be a question of synchronization here 
13:42 < bitconner> for 620 i think the general consensus is actually to exclude announcement_signatures rather than include them as BOLT 7 msgs
13:43 < rusty> Yeah, I think there are a number of things gated by funding_locked *exchange* ie. both sides say they've seen it.
13:43 < bitconner> can update the pr if people agree
13:43 <+roasbeef> related question is that should impls just be able to handle things slightly out of order for robustness purposes 
13:43 < BlueMatt> I think if the spec says order must be X, you dont need to handle it
13:43 < BlueMatt> if spec doesnt say that, then you do?
13:43 < BlueMatt> thats the point of a spec :p
13:44 < rusty> Ack #657 BTW
13:44 < BlueMatt> and, generally, gating things on funding_locked is nice cause thats an explicit indication, as rusty says, that you've seen it
13:44 < BlueMatt> and that you're ready to go
13:44 <+roasbeef> sure impls can be very strict, but then they may poorly handle edge cases where resumption is possible 
13:44 < rusty> #620 is exactly wrong.  announcement_signatures is *not* a bolt 7 message, and having it there was a mistake.
13:45 <+roasbeef> the thing here again is timing, if they other preson doesn't know of the channel yet (say slow processing) they can't process the update 
13:45 <+roasbeef> but you can say, shuoldn't they be expecting that channel given that the funding flow finished? 
13:45 < rusty> roasbeef: yeah, so you wait until they say they're ready, and problems vanish.
13:45 < bitconner> rusty: that doesn't rectify the fact that it *is* there :)
13:45 < BlueMatt> concept ack 657, tho I'd like some wording clarifications
13:46 < cdecker> ACK #657 :-)
13:46 < rusty> bitconner: indeed! But saying that it's "independent of particular channels" is just ridiculousness.
13:46 < rusty> I will propose removing it from bolt 7.  I think the desire was to reduce the amount of stuff in bolt 2.
13:46 < bitconner> maybe moving it out of bolt 7 is the real fix haha
13:46 < BlueMatt> ack moving it out of bolt 7 :)
13:47 < bitconner> okie doke
13:47 < t-bast> ack
13:47 < bitconner> #action connder to fine new home for announcement_signatures
13:48 <+roasbeef> rusty: why wouldn't they be ready? the've had 3 confs 
13:48 <+roasbeef> this feels like more of an implementation issue
13:48 < rusty> It's not a "gossip" message, by any stretch.
13:49 < rusty> roasbeef: there's no agreed short_channel_id until it's hit the depth specified.
13:49 < bitconner> 657 also introduces more ordering requirements on retransmission, which makes the section touched in 620 incorrect
13:49 < rusty> Until we both acknowledge that has been reached, messaged with a scid are meaningless.
13:49 < BlueMatt> roasbeef: because speed of light is not infinite
13:50 < bitconner> so on its own idt 657 is complete
13:51 <+roasbeef> #action #657 to have wording clarified on PR
13:51 <+roasbeef> lol sorry if i'm slow, in another meeting 
13:51 <+roasbeef> #topic 656
13:51 <+roasbeef> (bolt 11 feature bits)
13:51 <+roasbeef> related to the amp stuff 
13:52 < bitconner> ack
13:52 <+roasbeef> basically to have bits on the invoice to signal what type of payments the receiver accepts 
13:52 <+roasbeef> which can then possilby gate additional tags, such as the stream_id in the current amp draft 
13:52 < cdecker> ACK
13:52 <+roasbeef> comments on the PR are pretty minor, so maybe we leave it to there unless there're burning questions? (also to get to other stuff) 
13:53 < rusty> Yeah, future expandability FTW.  I mean, optional fields are good, but if they only need a single bit it's overkill, and there's no other way to say "if yuo don't udnerstand this, you're screwed".
13:53 < t-bast> ACK 656
13:54 < t-bast> Can we spend some time on 557?
13:54 <+roasbeef> #action general acceptance of #656, to hash out on PR 
13:54 < rusty> (The best thing about IRC meetings is I can cook breakfast at the same time and nobody knows!)
13:54 <+roasbeef> #topic #577 (range queries) 
13:55 < t-bast> #link https://github.com/lightningnetwork/lightning-rfc/pull/557
13:55 < bitconner> last i looked 557 was pretty close, haven't validated the test vectors myself tho
13:55 < t-bast> c-lightning supports this with the experimental flag and it inter-operates with eclair correctly (sstone correct me if I'm wrong)
13:55 < t-bast> bitconner do you have a draft implementation?
13:56 < bitconner> we do not atm
13:56 < t-bast> ok
13:56 < t-bast> what's your opinion on the PR as it stands though?
13:57 < rusty> We need confirmation of eclair interop, IMHO.  There were questions over final format (compression for checksums or not)
13:57 < sstone> yes I did basic tests against CL on master and eclair and CL can talk to each other and understand their queries
13:57 < t-bast> I think we agreed to drop compression for checksums last time
13:57 < sstone> rosabeef: we ditched compression for checksums
13:57 < bitconner> and drop the encoding type iirc
13:58 < t-bast> exactly
13:58 < t-bast> I think the PR has been updated accordingly and implementations too, right?
13:58 < sstone> yes PR, eclair and CL and up to date afaik
13:58 < bitconner> pr looks good to me, in the future we should also consider an analogous method for querying node_announcments, but that can be separate
13:59 < rusty> sstone: OK, I am happy for this to be included then!
13:59 < bitconner> definitely a big improvement :)
13:59 -!- captjakk [~captjakk@73.95.137.98] has joined #lightning-dev
13:59 < rusty> ... in theory since our release is delayed, I could remove the experimental gate on release...
13:59 < BlueMatt> rusty: where are we on #513?
13:59 < BlueMatt> or, can we talk about that next
13:59 -!- captjakk_ [~captjakk@2601:282:1300:286b:a19f:75be:6d74:71c4] has joined #lightning-dev
14:00 < sstone> rusty: when is your release planned ? I can do more comprehensive tests now (was traveling last week)
14:00 < t-bast> Do we think we're ready to drop the experimental gate for CL and Eclair release and merge 557?
14:01 < rusty> sstone: we're a few days overdue already, was hoping for final tomorrow.  I think it's too late, but next release in 8 weeks for sure.
14:01 <+roasbeef> (queue'ing up #513 as next topic) 
14:02 < t-bast> ok let's be safe and keep it as experimental for now then, but shall we merge 557 once more tests have been done between Eclair and CL?
14:02 <+roasbeef> main thing of #577 now seems to need for itnerop tests? 
14:02 < bitconner> i think so, yes
14:03 < rusty> sstone: I haven't completed my protocol tests for 557, which I can do this week too. 
14:03 < rusty> t-bast: ack
14:03 <+roasbeef> #info CL and eclair working on interop, CL working on further tests then can start 
14:03 -!- captjakk [~captjakk@73.95.137.98] has quit [Ping timeout: 244 seconds]
14:03 < t-bast> ack
14:03 <+roasbeef> #action 577 mostly reeady to go, gated on interop tests between CL and eclair, lnd to follow later (but not blocking) 
14:03 < bitconner> ack
14:04 < t-bast> just for clarification, when roasbeef states 577 he does mean 557 ;)
14:04 < sstone> roasbeef, conner: do you plan to eventually implement it ? I think it's a good basis for INV-based gossip (but am biased obviously)
14:04 <+roasbeef> lol yeah 557 sorry 
14:05 <+roasbeef> would say we care more about the inv stuff, not sure there's a really strong over lap though depending on which way we go, as there's that other inv PR as well 
14:05 <+roasbeef> y'all know how I feel about channel updates n stuff, so I won't rehash that lol 
14:05 < niftynei> #action s/577/557/ 
14:05 <+roasbeef> #topic #642 (static remote key) 
14:05 <+roasbeef> ok i've mostly implemented this on the lnd side, but only outstanding comment is to have a funding flag 
14:06 <+roasbeef> so impls can initaite one or the other, even if they have the feature bit set
14:06 <+roasbeef> i think the impact of this PR depends on how impls do their key derivation 
14:06 < rusty> roasbeef: I've implemented too.  Hmm, I assumed if we both supported it, we both wanted it?
14:06 <+roasbeef> one other thing that dawned on me while implementing this and the tlv onion PR is the blow up in test scenarios (with the way our tests are at least)
14:07 <+roasbeef> due to the growing compat matrix 
14:07 <+roasbeef> but if I have optional, and someone connects to me, I need to know that they want the legacy 
14:08 <+roasbeef> also if people want to mix it for w/e reason, and also for older impls that may not have the newer stuff but still need basic compat on channel funding 
14:08 < cdecker> roasbeef: I'm afraid that combinatorial explosion will always be there if we add new features
14:08 < rusty> roasbeef: if someone doesn't offer it and it's optional for me, I know not to use it.  I'm hoping we can quickly (~1yr) move off the old style.
14:08 <+roasbeef> yeh, it just became a bit more real to me lol cdecker 
14:09 < cdecker> Hehe, yeah, in CL we're fighting the same issue as well, with more platforms that we deploy to
14:09 < rusty> and the resulting Travis timeouts!
14:09 <+roasbeef> rusty: so then old nodes just can't make channels as soon as the network starts to switch over? 
14:09 <+roasbeef> the diff is a hard change vs a more gradual one 
14:10 < bitconner> old nodes would use the original format, no?
14:10 < bitconner> since they wouldn't advertise the feature bit
14:10 <+roasbeef> i mean if a new node has the optional feature bit, and an old nodes want to open a chanenl, what then? 
14:10 < rusty> roasbeef: if everyone makes it a compulsory option (even) they won't even be able to connect any more!
14:10 <+roasbeef> if you have the funding flag, the old node sends the flag and then they know
14:10 < bitconner> they'd use the old format iiuc
14:10 < rusty> roasbeef: if you don't both offer it, it's old-style.
14:11 < rusty> If both offer it (odd or even) it's on.
14:11 <+roasbeef> so new nodes won't open channel w/ old nodes? 
14:11 < rusty> roasbeef: eventually, sure.
14:11 < bitconner> or only if the new node requires
14:11 < t-bast> during the transition new nodes should only optionally support it
14:11 < rusty> (This is true of any even feature of course)
14:12 < t-bast> for X releases just make the default be optional
14:12 <+roasbeef> ok i guess it's a diff of explicit vs implicit negotiation 
14:12 <+roasbeef> explicit being to send the flag, implicit being to do logical and of feature bit existence 
14:13 <+roasbeef> but for interop, it seems useful to have a new node open an old channel 
14:13 <+roasbeef> as we'll still want to test this legacy format for some period of time, for eaxmple in cdecker's tests 
14:13 < t-bast> yes, but that's just a matter of changing configuration files for some tests
14:14 <+roasbeef> as an eaxmple for lnd, we now have a build tag for legacy features that lets you toggle them on, while we default to the newer stuff internally
14:14 <+roasbeef> well that depends lol 
14:14 < t-bast> oh you don't enable it by environment flags or config?
14:14 < t-bast> it's really set at build time?
14:14 <+roasbeef> what? legacy stuff? it depends 
14:14 <+roasbeef> there's a lot of ways to do it 
14:14 < rusty> roasbeef: sure, and my protocol tests test this (https://github.com/lightningnetwork/lightning-rfc/pull/655) (well, I havent pushed the static remotekey tests yet)
14:14 <+roasbeef> but the other comment on there was about the existing DLP stuff 
14:14 <+roasbeef> and if we can "remove" fields on not 
14:14 <+roasbeef> or not 
14:15 <+roasbeef> as is we can't since this message was created pre-tlv, so you need to have som eplace holder there if we want to extend it in the future 
14:15 < bitconner> imo it's better to leave blank than remove
14:16 < cdecker> Ultimately the cdecker/lightning-integration tests will need to be replaced by Rusty's more targetted tests, since we already have a combinatorial nightmare
14:17 <+roasbeef> just glanced at rusty's thing (hadn't seen it before), but can we use json rather than some custom grammar? 
14:17 < rusty> roasbeef: No, I tried that and it's unwritable :(
14:17 <+roasbeef> less parsing to do 
14:17 <+roasbeef> but this isn't easily machine readable 
14:18 <+roasbeef> you can still have comments/commentary as well 
14:18 <+roasbeef> but this is anotehr topic, ok so maybe we don't need that funding flag and we can make things implicit 
14:18 <+roasbeef> the remainder we can hash out on the PR?
14:18 <+roasbeef> lnd's impl should be ready this week, so we can start testing 
14:19 < bitconner> hash out on pr sgtm
14:20 < rusty> roasbeef: ack!
14:20 < t-bast> sgtm
14:20 <+roasbeef> #action stick with only feature bit on #642, next steps are interop 
14:20 <+roasbeef> #topic 627 
14:20 <+roasbeef> (onion falire code)
14:20 <+roasbeef> rn for lnd we send invalid onion key iirc, but would be nice to give the sender more context 
14:21 < t-bast> ok good to know
14:21 <+roasbeef> I guess there's a question of if there's some other probing vector here 
14:21 < t-bast> I changed eclair to just send PERM right now
14:21 < rusty> I'd like to see an offset field in there, to provide a hint as to what in the onion we disliked...
14:22 <+roasbeef> or even the type? 
14:22 <+roasbeef> (tlv type) 
14:22 < t-bast> rusty: but that doesn't always make sense
14:22 <+roasbeef> assuming it awas a parsing failure 
14:22 <+roasbeef> maybe we should reduce the scope and add another type if needed? 
14:22 <+roasbeef> the use case I have in mind is "i can't parase this type" or "i don't know of this type" 
14:22 < t-bast> that doesn't cover the case where we're missing data (or we put as offset the length of the tlv stream)?
14:23 < t-bast> I think this is more general, we also have to cover the case "you didn't include all the types I need to process this"
14:23 <+roasbeef> two paths again here: more specific information for debugging, or more vague information to just signal that we're unable to proceed 
14:23 < rusty> t-bast: missing data, yes I think so.  I think we;ve enjoyed the debugging hints when we've added them to msgs, OTOH FFS TLV isn't that hard :)
14:24 < t-bast> rusty: heh
14:24 < t-bast> so should I update this PR to list more explicitly all the cases covered by this and add an offset field? anything else you'd like to see in there?
14:24 < bitconner> on a tlv-related note: be sure to add a soft cap when decoding varbytes, o/w someone can trivially cause you to oom
14:24 < t-bast> I don't think it introduces a probing vector, but if you do find one I'm interested
14:25 < bitconner> thanks to eugene for fuzzing our tlv library!
14:25 < t-bast> bitconner: yep ;)
14:26 <+roasbeef> ok so we're leaning towards keeping the error general then? 
14:26 <+roasbeef> or minimally add a type and some length offset? 
14:26 < t-bast> I think type + length offset would be useful
14:26 < t-bast> and can be removed in X releases once we're confident implementations interoperate flawlessly
14:27 < bitconner> tbh i'd rather add it later than try to remove it down the road
14:27 < rusty> t-bast: we'll want it in as we add new TLV fields anyway.
14:27 <+roasbeef> #action possibly add type+length offset to #627, need of some sort is clear 
14:28 < rusty> t-bast: offset is offset within onion or within specific TLV...
14:28 <+roasbeef> do we want to conclude? or can ppl hang around? 
14:28 < t-bast> rusty: I'll brainstorm this and propose something on the PR
14:28 < bitconner> thoughts on https://github.com/lightningnetwork/lightning-rfc/pull/660?
14:28 < bitconner> pretty easy 1
14:29 < t-bast> could we quickly merge 601? It's been there for ages and is a quite simple clarification (with approvals already)
14:29  * cdecker waves, needs to run off :-)
14:30 < t-bast> 660: I put some comments in there, I think that it either needs to be a simple tlv "property bag" that we define for that specific use-case, or we should have a more general discussion on what feature flags / tlv types devs can use for experimentations
14:30 < bitconner> 601 lgtm
14:30 < t-bast> something like what z-man proposed with "I can haz extension", extended to cover "I can haz tlv"
14:31 < t-bast> bitconner: thx, can I merge it then (we already had rusty's ack)
14:32 < bitconner> t-bast: i think those are slightly different tho
14:32 <+roasbeef> oh yeh the question of experimetns is coming up again 
14:32 <+roasbeef> basically how can devs experiment with new funding or channel stuff, that doesn't deviate too far from the current protocol 
14:33 < t-bast> yeah I think this is a more general discussion and #660 is either too specific or not general enough
14:33 < t-bast> let me rephrase that
14:33 < bitconner> discussion leading up on tlv stuff was that we'd allow people to experiment with their own tlv records, tho we never defined which ones would be reserved for official spec use
14:33 < t-bast> #660 should either be very specific and solve only the mentioned use-case of an opaque property bag for onion tlv, or touch on the general subject of experimenting with new tlv types without impacting the network
14:34 <+roasbeef> t-bast: wells there's two dimensions: the onion and general message extensions 
14:34 < t-bast> if we start the general discussion of reserving tlv type ranges, I think it would make sense to group it with "I can haz extension"
14:35 <+roasbeef> i didn't get that extension thign 
14:35 < t-bast> I think both should use the same kind of mechanism / ranges (or at least we should consider it)
14:35 <+roasbeef> i guess the q is where should the signaling be done, in the protocl or outsside to reserve ranges 
14:35 < lndbot> <joost.jager> my main q around 660 is whether a single opaque tlv field for user data would have any down sides compared to multiple custom fields that can be picked from a range.
14:36 <+roasbeef> it restricts devs imo 
14:36 <+roasbeef> as now there's on slot
14:36 <+roasbeef> also not like we're short on types with 64 bits 
14:36 < t-bast> that's honestly an interesting question because it's not only technical, it also touches on coordination in an open p2p network
14:36 <+roasbeef> one* 
14:36 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 268 seconds]
14:37 < bitconner> i dislike the idea of cramming all extensions into a single tlv record
14:37 < bitconner> we have 2^64 options
14:37 < t-bast> definitely
14:37 <+roasbeef> it could be as light weight as resreve 16 or so bits, then have ppl shout out on the ML what they're using
14:38 < lndbot> <joost.jager> yes, people can even put their own tlv into the single tlv fields, but it isn't necessary.
14:38 <+roasbeef> then if stronger coordination is needed, we'll see the pain points 
14:38 < t-bast> but how do we allow people to pick values (tlv types of message types) that they can "safely" use to experiment by forking an existing implementation without negative impact on the network - that's what we need a solution to
14:38 <+roasbeef> (speaking of onion tlv only) 
14:38 <+roasbeef> what negative impact would you see t-bast ?
14:38 <+roasbeef> assuming it's mostly at sender/receiver
14:38 <+roasbeef> and intermediate nodes can use that error to say "i don't understand this" 
14:38 < t-bast> just two dev teams inadvertently using the same values for two different things and thus breaking each other's feature
14:38 < bitconner> t-bast: read from /dev/random :)
14:39 < t-bast> bitconner: that's a solution :)
14:39 < bitconner> t-bast: i think leaving things open for experimentation will always result in possible collisions to some extent
14:39 < t-bast> bitconner: and then if you want to promote this to a spec-ed thing you re-assign and update nodes?
14:39 < niftynei> +1 for a range. we could put up wiki page on the rfc repo for 'claiming' extension numbers
14:40 < bitconner> worst case most likely is just a parsing failure
14:40 < t-bast> a wiki page or a github issue where anyone could grab available values could be a start
14:40 < niftynei> ideally some page that's pretty widely editable
14:40 < bitconner> i hereby reserve all unreserved types
14:40 < t-bast> but append-only ideally
14:40 <+roasbeef> would like to do it in a way that involved as little coordination as possible 
14:40 < niftynei> having a singular document rather than a comment set (issue) is preferable imo
14:41 <+roasbeef> for example, the colored coins people are attepmting something more aggressive 
14:41 <+roasbeef> basically a sub-protocol
14:41 <+roasbeef> to what extend do we all need to be involved in that? 
14:41 < niftynei> yeah a globally editable page (wiki) with a changelog history seems ideal
14:41 < bitconner> my main concern with a doc would be the opportunity for squatting
14:41 < t-bast> if they really launch something and depend on the values they chose, at some point this needs to be spec-ed somewhere to avoid collision - I'm not sure how we should be involved in that
14:41 <+roasbeef> bitconner: you snooze you lose 
14:42 < niftynei> having them all in one place rather than spread out over the mailing list is nice for discoverability
14:42 <+roasbeef> t-bast: yeh but imo would rather allow ppl to experiment w/o having to always go thru the spec process, and the ML is enogh for that in the short term imo 
14:42 < bitconner> tlv.casino
14:42 < niftynei> :D
14:42 < niftynei> high rollers only
14:42 <+roasbeef> (again there's two optics in flight tlv in the onion and arbitrary tlv extensions on all messages)
14:42 <+roasbeef> topics* 
14:42 <+roasbeef> kek
14:42 < t-bast> roasbeef: I completely agree that the spec process isn't what should be used, but I'd like to brainstorm what we can use :)
14:42 -!- queip [~queip@unaffiliated/rezurus] has joined #lightning-dev
14:42 <+roasbeef> biiiiig monay 
14:42 < lndbot> <joost.jager> the main intention of the pr was to at least define and defend (with constraints in the implementation) an official range. a second question is how to coordinate the experiments range.
14:43 < niftynei> i'm +1 for a range designation
14:43 < t-bast> agreed
14:43 < t-bast> but
14:43 < t-bast> I don't understand why you only did that for onion tlv
14:43 < t-bast> imo it makes sense to define a tlv range open for experimentation for all tlv in all messages
14:44 < bitconner> i'm in favor of formalizing the range, i think 2^32 is plenty for our use case, but yes should apply to all tlv types
14:44 < t-bast> bitconner: sgtm
14:45 < lndbot> <joost.jager> pr was written in line with my current focus. we could generalize that, but does it need to be a single pr?
14:45 < bitconner> as far as coordination, seems like it should roughly translate to the problem of choosing default ports, but with much lower collision rate
14:46 < bitconner> self-coordination works for the most part :)
14:46 < t-bast> joost: I think it will end up being a small PR even if we say this range applies to all tlvs, and it's not too costly to do the general one from the start
14:46 < bitconner> possibly the change should be in bolt 1 then?
14:46 < t-bast> we can probably start without specifying coordination, and suggesting using randomness to avoid collisions
14:46 < lndbot> <joost.jager> for custom tlv in the onion, it may also be useful to distinguish between key/values that are just passed on without any interpretation to higher level applications and types that are used internally in forked versions of node software
14:47 < t-bast> I think it would make sense in Bolt 1 yes
14:47 < t-bast> joost: I think that's a different issue: this is solved by assigning a tlv type in the onion namespace to act as a property bag
14:47 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 258 seconds]
14:47 < lndbot> <joost.jager> the range can be defined in a generic way, but at least for the onion there are still some specific directions on how to deal with it as a reader and writer
14:48 < bitconner> joost: does that mean even/odd rule wouldn't apply to "big" types?
14:48 < lndbot> <joost.jager> t-bast: is there consensus on that already?
14:48 < niftynei> should we only open up odd types in a range?                                                                           
14:48 < t-bast> joost: not yet I think, that's just my 2 cents ;)
14:48 < lndbot> <joost.jager> i am not sure what the best decision is there. is assumed we only use the odd types
14:49 < bitconner> if the fields are being passed to the application layer, then likely the software won't ever know the encoding
14:50 < t-bast> it depends, if you want to experiment with something that forks away from the main network you can use even experimental tlv types for that - but that's probably not a common use-case
14:50 < bitconner> we could petition the gods of math to make all numbers > 2^32 odd, but may be a bigger change
14:51 < t-bast> I think we should simply explain that users should pick odd numbers if they want to interact with the main network, and that they may pick even number but in that case they'll likely fork the network
14:51 < t-bast> and they'll be in a very small fork :)
14:51 < bitconner> sgtm, add range + recommend odd
14:52 < lndbot> <joost.jager> ok. and a defined `user_data` field, we'll drop that then?
14:52 < t-bast> I think that's a separate PR imo
14:53 < lndbot> <joost.jager> if we have the custom range, why would I use the user data field then still?
14:53 <+roasbeef> you wouldn't lol
14:53 < t-bast> if you don't need it anymore once you have the range, perfect then!
14:53 < t-bast> we can forget about it ;)
14:53 < lndbot> <joost.jager> Ok, clear then :slightly_smiling_face:
14:53 < t-bast> I gotta go, thanks guys see you next time!
14:54  * bitconner waves to t-bast
14:55 < lndbot> <joost.jager> leaving too, bye!
14:55 -!- t-bast [~t-bast@2a01:e34:ec2c:260:b05f:4b89:740:1fce] has quit [Quit: Leaving]
14:55 < bitconner> time to conclude?
14:55 < bitconner> #endmeeting
14:57 < BlueMatt> rusty: where are we on #513?
14:58 < BlueMatt> specifically, looks like core may be able to land all the required bits for the next release
14:58 < BlueMatt> and its...uhhh...kinda critical to the lightning security story
14:59 -!- joostjgr [~joostjag@ip51cf95f6.direct-adsl.nl] has quit [Ping timeout: 245 seconds]
15:03 <+roasbeef> BlueMatt: that's been split into two pr s
15:03 <+roasbeef> one that does the key derivation change, and the other that'll do the fee related stuff 
15:04 <+roasbeef> even once they land, it'll be some time for relaying nodes to update, so we can go w/ a staged version: add the hooks, keep in update_fee (to set a base line) 
15:06 -!- rh0nj [~rh0nj@88.99.167.175] has quit [Remote host closed the connection]
15:06 < BlueMatt> roasbeef: huh? what do you mean keep in update_fee?
15:07 -!- rh0nj [~rh0nj@88.99.167.175] has joined #lightning-dev
15:07 < BlueMatt> roasbeef: its a per-node decision? I mean sure people have to update but it only effects your own channels with your peers
15:07 < BlueMatt> not across the network
15:07 < BlueMatt> roasbeef: it may be useful to comment on github what the status of things is, so that people can see it :p
15:11 -!- hiroki_ [a331cc5f@95.204.49.163.rev.vmobile.jp] has quit [Remote host closed the connection]
15:11 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.]
15:13 -!- hiroki_ [a331cc5f@95.204.49.163.rev.vmobile.jp] has joined #lightning-dev
15:16 -!- sstone [~sstone@li1491-181.members.linode.com] has quit [Quit: Leaving]
15:17 -!- captjakk_ [~captjakk@2601:282:1300:286b:a19f:75be:6d74:71c4] has quit [Remote host closed the connection]
15:17 -!- captjakk [~captjakk@2601:282:1300:286b:a19f:75be:6d74:71c4] has joined #lightning-dev
15:17 -!- melvster [~melvin@ip-86-49-18-190.net.upcbroadband.cz] has quit [Remote host closed the connection]
15:18 -!- captjakk [~captjakk@2601:282:1300:286b:a19f:75be:6d74:71c4] has quit [Remote host closed the connection]
15:18 -!- captjakk [~captjakk@c-75-71-171-239.hsd1.co.comcast.net] has joined #lightning-dev
15:18 -!- melvster [~melvin@ip-86-49-18-190.net.upcbroadband.cz] has joined #lightning-dev
15:19 -!- captjakk [~captjakk@c-75-71-171-239.hsd1.co.comcast.net] has quit [Remote host closed the connection]
15:19 -!- captjakk [~captjakk@c-75-71-171-239.hsd1.co.comcast.net] has joined #lightning-dev
15:19 -!- captjakk [~captjakk@c-75-71-171-239.hsd1.co.comcast.net] has quit [Remote host closed the connection]
15:20 -!- captjakk [~captjakk@c-75-71-171-239.hsd1.co.comcast.net] has joined #lightning-dev
15:20 -!- captjakk [~captjakk@c-75-71-171-239.hsd1.co.comcast.net] has quit [Remote host closed the connection]
15:20 -!- captjakk [~captjakk@2601:282:1300:286b:a19f:75be:6d74:71c4] has joined #lightning-dev
15:21 -!- captjakk [~captjakk@2601:282:1300:286b:a19f:75be:6d74:71c4] has quit [Remote host closed the connection]
15:21 -!- captjakk [~captjakk@c-75-71-171-239.hsd1.co.comcast.net] has joined #lightning-dev
15:22 -!- captjakk [~captjakk@c-75-71-171-239.hsd1.co.comcast.net] has quit [Remote host closed the connection]
15:22 -!- captjakk [~captjakk@c-75-71-171-239.hsd1.co.comcast.net] has joined #lightning-dev
15:23 -!- captjakk [~captjakk@c-75-71-171-239.hsd1.co.comcast.net] has quit [Remote host closed the connection]
15:37 -!- hiroki_ [a331cc5f@95.204.49.163.rev.vmobile.jp] has quit [Remote host closed the connection]
15:45 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #lightning-dev
15:46 -!- marcoagner [~user@2001:8a0:6a53:2e00:1967:22be:ad77:2d5] has quit [Ping timeout: 252 seconds]
16:00 <+roasbeef> BlueMatt: i mean an intermediate stage where that's still used to handle fees, and we aren't solely depending on the CPFP mechanism 
16:00 <+roasbeef> oh that other PR is up, we discussed it a bit earlier 
16:02 <+roasbeef> #endmeeting
16:02 < lightningbot> Meeting ended Mon Aug 19 23:02:51 2019 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
16:02 < lightningbot> Minutes:        http://www.erisian.com.au/meetbot/lightning-dev/2019/lightning-dev.2019-08-19-20.11.html
16:02 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/lightning-dev/2019/lightning-dev.2019-08-19-20.11.txt
16:02 < lightningbot> Log:            http://www.erisian.com.au/meetbot/lightning-dev/2019/lightning-dev.2019-08-19-20.11.log.html
16:03 <+roasbeef> soz forgot to earlier :p 
16:03 -!- Amperture [~amp@24.136.5.183] has joined #lightning-dev
16:03 < lndbot> <moli> :rofl:
16:03 < BlueMatt> lololol
16:03 < lndbot> <moli> i kept waiting for the log, @roasbeef, thanks :)
16:04 < BlueMatt> roasbeef: I dont think such an intermediate state makes sense?
16:04 < BlueMatt> roasbeef: I dont see why it would be required?
16:05 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev
16:07 <+roasbeef> if we want to be able to allow fees after the fact, without relying on some sort of package relay structure or other relay related changes BlueMatt 
16:07 <+roasbeef> in the short term at lease 
16:07 <+roasbeef> t
16:10 < BlueMatt> roasbeef: huh?
16:10 < BlueMatt> roasbeef: we've landed the stuff in core
16:11 < BlueMatt> roasbeef: at this point its gonna be available on the broader p2p network longgggg before anything in lightning uses it
16:11 < BlueMatt> hence why I'm asking about it
16:11 <+roasbeef> ok, but that's still pending a release and wider deployment 
16:11 <+roasbeef> update on it is that a portion of it was split out, but don't know if others know things in bitcoind have been merged in 
16:11 < BlueMatt> <BlueMatt> roasbeef: at this point its gonna be available on the broader p2p network longgggg before anything in lightning uses it
16:12 < BlueMatt> <BlueMatt> roasbeef: we've landed the stuff in core
16:12 < BlueMatt> see ^
16:12 <+roasbeef> am I speaking to the matt within the matt? 
16:12 < BlueMatt> my point is that yes, we have landed the bits in core
16:12 <+roasbeef> i understand that, and as I said it'll take time to roll out, so if we wanted to go with a more restricted version, we could do so 
16:12 <+roasbeef> it would also give impls time to get their CPFP logic, etc correct 
16:13 <+roasbeef> as they wouldn't rely on it 100% 
16:13 < BlueMatt> right, but if you're worried about getting it correct, then dont use it and just dont default-enable the new channel flags?
16:14 < BlueMatt> right, my point is that it'll be reasonaly deployed on the network long before anyone in lightning uses it
16:14 < BlueMatt> I mean the whole update_fee dance is....really stupid from a "relying on this for security" perspective
16:14 <+roasbeef> even if one party doesn't use it, depending on who's closing, it may give another party an ability to affect fees that they don't have rn 
16:15 -!- melvster [~melvin@ip-86-49-18-190.net.upcbroadband.cz] has quit [Ping timeout: 245 seconds]
16:15 <+roasbeef> don't see how you can make such strong claims w.r.t timing though 
16:16 < BlueMatt> I mean its already merged and the next version of core is in like 2-3 months?
16:17 < BlueMatt> getting a spec change more thouroughly reviewed and implemented, then merged, then released seems like a 6+ month process
16:17 < BlueMatt> not to mention, as you point out, people writing cpfp-based tx broadcasting that they're comfortable with being stable/reliable
16:17 <+roasbeef> thought the next release got pushed back to jan 2020? not keeping up it seems, but even then you'd need upgrade time ofc 
16:17 <+roasbeef> yeh lnd has that code already in prep, but dunno how ready the others are 
16:18 <+roasbeef> but i think you have your update now? the PR got split off, and the other one can be resumed if stuff is on the way 
16:20 < bitconner> the main reason, i thought, for the intermediate step was to expedite safety of user funds via a very isolated change with no dependencies
16:21 < BlueMatt> feature freeze for core 19 is in ~ 1 month
16:21 < BlueMatt> https://github.com/bitcoin/bitcoin/issues/15940
16:22 < BlueMatt> bitconner: which intermediate step? the change for the key types separate from the removal of fee crap?
16:23 < bitconner> BlueMatt: yeah static key -> full redesign
16:24 < BlueMatt> right, I mean those are rather independant things, tho dont know why either has to come before the other
16:24 < bitconner> well the fee change has dependencies while the other doesnt
16:25 < BlueMatt> though from a security perspective, I dont really quite understand the lack of urgency on the udpate_fee stuff. I mean the current state of things seems *really* insecure (though obviously getting a whole new broadcast method built takes careful work)
16:25 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.]
16:25 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 248 seconds]
16:30 < bitconner> in general i agree, tho im not aware of anyone who's lost money due to the fee issues, while people have lost real money bc of the tweak and inconsistencies in dlp implementations
16:39 <+roasbeef> ^ yup
16:40 < bitconner> iirc, not all implementations continue to send dlp info after a channel is closed, which is an immediate (and easily fixable) danger to users' funds
16:43 <+roasbeef> also update_fee changes don't have any affect on broadcast, since it's a link level thing 
16:47 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #lightning-dev
16:59 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 245 seconds]
17:05 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #lightning-dev
17:06 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev
17:11 -!- queip [~queip@unaffiliated/rezurus] has joined #lightning-dev
17:21 < rusty> BlueMatt: it's deeply unclear that it's better if we were to roll it out today.  During a fee spike, your tx won't broadcast because fees are too low anyway, so you're screwed.  But in addition you need to rewrite your wallet to be much smarter than it is today, to weave a new tx to do CPFP; thus you need to keep an onchain reserve, and update that tx as conditions change, such as another channel unilaterally closing, or the count
17:21 < rusty> erparty's unilateral close winning the race.  You end up with multiple trees of txs to juggle, whereas you don't need that logic today.
17:23 < BlueMatt> I mean you do need various trees of htlc punishment txn and resolutions today, for the momst part, but I dont really get your comment?
17:24 < BlueMatt> well, two parts I dont get, first of all "better than today", well today's world is "oops fees went up, now you're fucked", so I don't see how it could get much worse
17:24 < BlueMatt> but, also, "During a fee spike, your tx won't broadcast because fees are too low anyway, so you're screwed." <- this, are you referring to the need for some form of package relay?
17:25 < rusty> BlueMatt: yes.
17:26 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 244 seconds]
17:27 < aj> i don't think we're too far away from some form of package relay
17:27 < rusty> BlueMatt: today, we have a single daemon which handles onchain channel closures, according to simple rules.  It responds when it sees txs at a given depth, and it perfectly replayable.  If there's a reorg, we simply kill it and start again.
17:28 < rusty> We never have to unpick unrelated txs and combine them together, as we would have to do for CPFP.
17:28 < rusty> (Now, such tx management would be awesome anyway, ebcause it would make penalty txs more efficient, but it's not a priority)
17:30 < rusty> Our wallet logic is very dumb.  We never have to ask it "hey, can you provide an input for fees?" or "can you provide a whole tx for CPFP?".
17:42 -!- mdunnio [~mdunnio@208.59.170.5] has joined #lightning-dev
17:50 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #lightning-dev
18:01 -!- mdunnio [~mdunnio@208.59.170.5] has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
18:16 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 244 seconds]
18:16 -!- riclas [~riclas@77.7.37.188.rev.vodafone.pt] has quit [Ping timeout: 268 seconds]
18:18 <+roasbeef> imo the on chain fee reserve component is probably the most challenging, due to the fact that many wallets want to surface "only LN" to the end user, but now they'll also need to allocate some on-chain balance to be able to close out channels (if/when we go the extreme route of zero fees on the commitment transaction assuming packaged relay) 
18:20 <+roasbeef> challenging from a UX perspective* 
18:23 < rusty> roasbeef: yeah; I mean, at some point you can assume you can splice out of another channel, but that requires some trust...
18:27 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has joined #lightning-dev
18:37 < aj> rusty: pay over lightning for a coinjoin from someone else's on-chain utxo to fund your fees?
18:38 < rusty> aj: trust required AFAICT?
18:39 < aj> rusty: hmm, not if you add in schnorr scriptless scripts?
18:43 < rusty> aj: I mean, I'm not sure what the effective difference between "I assume I'll be able to make a lightning payment" and "I assume I can close/splice-out a channel" is?  If all your peers conspire, you need onchain funds.
18:44 < aj> rusty: oh, i was figuring splicing out was harder than making a lightning payment (you need to fund it with fees too?) as the problem
18:44 < rusty> aj: well, a splice (handwave) would be funded with lightning fees...
18:45 < rusty> But you can always mutual close as a poor-man's splice
18:47 < aj> if you don't have onchain funds and all your peers are conspiring and fees are high enough that your commitment transactions don't confirm, you're pretty screwed?
18:47 < rusty> aj: yes.  Hence the balance.
18:53 < aj> i guess you could get out of that by nominating some peers as trusted-not-to-conspire-against-you, but a balance is probably better
19:06 <+roasbeef> aj: yeh I think that can work post no_input 
19:06 <+roasbeef> (fee close coin join) 
19:07 <+roasbeef> alternatively there're also sub-swap services such as Loop that people can use, so you'd send out some of your balance on-chain then spend that HTLC directly into your channel close if no input, or use to provide fees for an anchor output 
19:19 < aj> rusty: hmm, you don't really need peers to conspire for that failure mode, just for them all to go unreachable at once (maybe your isp is blocking you, maybe they were all in one area by coincidence and suffered from a natural disaster)
19:19 < rusty> aj: yes, indeed.
19:21 < rusty> roasbeef: it's easier to do that with a direct peer splice eventually, but yes.
19:34 <+roasbeef> what if it's your only channel tho? (re splicing), i'm assuming you mean use that as a way to grab funds from another channel to pay for the closing of another? 
19:36 < rusty> roasbeef: Don't Do That :)
19:37 < rusty> roasbeef: you need onchain reserves until your channels are sufficiently diverse.  Whatever that means!
19:47  * roasbeef writes in a row of ??? -> profit to the requirements section in the spec draft 
19:50 < rusty> LOL
20:52 < rusty> roasbeef: I'm thinking we should add a new (odd) msg "warning".  Since error is supposed to be "oh crap, close channels" and that's proven too harsh in general, perhaps we should migrate to a warning.  Gives a clue something is wrong, but doesn't mean the channel is toast.  Or we could do the other way and downgrade "error" and ahve a new "close channel" (even) msg.
22:08 <+roasbeef> rusty: i have a draft of converting to error codes locally here
22:08 <+roasbeef>  main thing I was meant to next was check out all the impls for their various error cases to add as codes to the message 
22:09 < rusty> roasbeef: cool... I would leave that auditing to the implementations themselves TBH.
22:09 <+roasbeef> so first byte or two is the code, then beyond that arbitrary data, but data may have a sturcture defined by the code, for example a transaction 
22:09 < rusty> (You write the spec, you get to choose the codes!)
22:09 <+roasbeef> yeh was meant to be on a broader basis, for example, this timeout chan reest thing would've been in that 
22:10 < rusty> roasbeef: yeah, that's a classic "warning" style erorr.  I mean, it's not *actionable*: you get that errro, what do you do?  You either hang up and retry, or just log it and hope for post-mortem when people try to figure out why their channel isn't working.
22:13 -!- joostjgr [~joostjag@ip51cf95f6.direct-adsl.nl] has joined #lightning-dev
22:54 -!- melvster [~melvin@ip-86-49-18-190.net.upcbroadband.cz] has joined #lightning-dev
23:13 -!- joostjgr [~joostjag@ip51cf95f6.direct-adsl.nl] has quit [Ping timeout: 272 seconds]
23:19 -!- StopAndDecrypt [~StopAndDe@107.181.189.42] has joined #lightning-dev
23:20 -!- StopAndDecrypt [~StopAndDe@107.181.189.42] has quit [Changing host]
23:20 -!- StopAndDecrypt [~StopAndDe@unaffiliated/stopanddecrypt] has joined #lightning-dev
23:21 -!- StopAndDecrypt_ [~StopAndDe@107.181.189.42] has quit [Ping timeout: 272 seconds]
23:25 -!- joostjager [~joostjgr@ip51cf95f6.direct-adsl.nl] has quit [Quit: Leaving]
23:55 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.]
--- Log closed Tue Aug 20 00:00:45 2019