19:06:09 <t-bast> #startmeeting
19:06:09 <lightningbot> Meeting started Mon Feb 17 19:06:09 2020 UTC.  The chair is t-bast. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:06:09 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:06:34 <t-bast> #topic Wumbo
19:06:45 <BlueMatt> rusty: you just need to install the caffeine drip before you go to bed so that it can start dripping into your veigns before your alarm goes off :p
19:07:07 <t-bast> #link https://github.com/lightningnetwork/lightning-rfc/pull/596
19:07:14 <t-bast> Anything holding up merging wumbo?
19:07:38 <t-bast> We agreed to work on an advisory on confirmation scaling, but we'll do that in a follow-up PR
19:08:23 <cdecker> Bit compaction has been done, so I think this is good to go
19:08:31 <rusty> t-bast:  ack!
19:08:51 <ariard_> hi
19:08:59 <cdecker> Hi Antoine
19:09:17 <t-bast> Great, Joost do you know if on LL side there's anything holding up the wumbo spec PR?
19:09:31 <joostjgr> No, not up to date on that one
19:10:06 <t-bast> We did agree during last meeting to merge this once the bits were updated, and roasbeef was there so I think we're good to go right?
19:11:40 <joostjgr> If that was the noted action
19:12:08 <t-bast> #action t-bast merge 596 and work with araspitzu on advisory PR for scaling confs
19:12:11 <joostjgr> As I said, I have not much to ack here. Coming for stuck channels and anchors
19:12:18 <t-bast> #topic TLV extensions
19:12:26 <t-bast> #link https://github.com/lightningnetwork/lightning-rfc/pull/714
19:13:06 <t-bast> Allright the points that are still to be discussed on this PR are the optional fields that need to be made mandatory
19:13:35 <rusty> Since this will go away in openchannel2, I believe making it mandatory is correct.
19:14:09 <t-bast> I'm proposing to interpret shutdown_script as a TLV field, which is more flexible
19:14:20 <roasbeef> didn't we cover this last time? to just make it zeroes?
19:14:24 <t-bast> I made a quite lengthy comment about why on the PR, which I'll let you digest :)
19:14:53 <roasbeef> also I don't really see "openchannel2" replacing what we have rn given the main benefit is dual funding, which itself can already be emulated using multiple single funder channels
19:14:54 <t-bast> hey roasbeef, yes we did, but needs a look at how the PR does that
19:15:35 <roasbeef> how does making it tlv help us remove the sender requirement? assume there's a node out there that never updated to tlv stuff but is opening channels, how can we remove that requirement ina backwrds compatible manner?
19:16:29 <t-bast> I don't think this is an issue
19:16:46 <rusty> t-bast: clever.
19:16:55 <t-bast> If our node offers the option_shutdown_script feature, it does offer it as a TLV, which the old node interprets as just the shutdown_script field
19:17:18 <t-bast> If our nodes doesn't, the old node isn't expecting a shutdown_script field and will ignore the whole tlv stream
19:17:32 <t-bast> (if there's anything written to that tlv stream of course)
19:17:46 <t-bast> rusty: yay it's not so hacky after all :)
19:18:02 <cdecker> As clever as the "interpret the bytes differently" solution is, it's a game we can only play once
19:18:06 <rusty> (I think we're going to have to shift to either a second key, or a bip 32 seed & range, in future, to allow splice out to be sensible).
19:18:44 <t-bast> cdecker: yes, but once we've moved to a tlv stream we shouldn't need that kind of trick unless we want something completely different from tlvs, right?
19:18:51 <t-bast> rusty: what do you mean?
19:19:16 <roasbeef> re wumbo: UX for it will be pretty poor w/o a way for the nodes to signal their max accepted channel
19:19:41 <niftynei> i believe it's to allow key-rotation for splicing out to different addresses; otherwise you'd have to re-use the address to comply with the upfront_shutdown script for multiple out splices
19:19:48 <cdecker> No, I'm saying we can only use this interpretation freedom on a single optional field, which is ok if upfront_shutdown_script is the only occurrence of this issue, but if there are any other optional fields appended we can't just give them TLV-type 0x00 again
19:19:50 <rusty> t-bast: option_upfront_shutdown_script assumes the only way to get funds out is shut down.  In future we have splice out.
19:19:55 <roasbeef> i think he means being able to obtain the "next series" w/o going thru the interaction to reduce round trips
19:20:06 <roasbeef> splice out and upfront shutdown aren't really compatible tho...
19:20:08 <t-bast> cdecker: got it, totally
19:20:28 <rusty> roasbeef: indeed.
19:20:31 <t-bast> rusty/niftynei: ah gotcha, but that shouldn't be an issue with non-upgraded nodes?
19:20:37 <roasbeef> cdecker: which I think is ok, as the optional fields aren't really optional, so if possible we can do this to all the existing ones to move to the "new world"
19:21:00 <rusty> t-bast:  all other TLVs must be > the longest possible shutdown script ofc.
19:21:50 <niftynei> i thought t-bast did an audit of existing fields this pertains to... upfront_shutdown and one other??
19:22:08 <roasbeef> there's max htlc too iirc
19:22:43 <t-bast> yes only your_last_per_commitment_secret/point and shutdown_script, max_htlc doesn't need to change as its presence is gated on the preceding byte (channel_flags IIRC)
19:22:48 <rusty> option_data_loss_protect / option_static_remotekey which are effectively compulsory on the network todat.
19:23:17 <t-bast> rusty: since I added a requirement that if you use a TLV stream, you have to include a shutdown_script, this shouldn't be an issue, is it?
19:23:47 <t-bast> rusty: you'd include either a valid one or a 0x0000 one if you don't care about shutdown_scripts
19:24:15 <rusty> t-bast: that would break compatibility with legacy once you do, if you use a type less than 0x22?
19:24:46 <t-bast> rusty: I don't think so, because the shutdown_script length is currently 2 bytes
19:25:16 <rusty> t-bast: oops, yes, type is 0, no lesser type possible.  OK, more coffee for me.
19:25:42 <t-bast> rusty: xD this clearly isn't the simplest PR for breakfast
19:26:56 <roasbeef> all follows for me, and as decker said above we can only really do this once, so might as well do it early so we can enjoy the new bountiful world of tlv (actually optional fields)
19:27:36 <cdecker> Yes, but don't we have a flat type-structure across all TLVs?
19:27:37 <rusty> It's an ack from me, too.
19:27:54 <roasbeef> cdecker: flat type? how's that related?
19:28:25 <cdecker> So what I meant before was that if we use the re-interpret trick on upfront_shutdown_script, we can't use it for option_static_remotekey, even though they might be in different messages
19:28:44 <roasbeef> but static remote key doesn't involve a new field
19:28:50 <cdecker> There is only one legacy optional field that can be type 0x00
19:29:06 <niftynei> i see what you're saying cdecker, i thought we agreed that TLV types are unique per message?
19:29:09 <t-bast> cdecker: why not? that's only if we want messages to share TLV records, right?
19:29:30 <t-bast> Yeah I thought we said each message is its own namespace for the TLV records it contains
19:29:33 <roasbeef> yeh unique per message
19:29:38 <cdecker> Don't we? I find it really confusing to have TLV-types be context dependent,
19:29:39 <niftynei> you're right in that if they're globally assigned this won't work again :)
19:30:01 <niftynei> i was also under the 'unique per message' assumption umbrella
19:30:36 <cdecker> Ok, I might be misremembering the discussion about this, but it's ugly af
19:31:05 <t-bast> xD
19:31:25 <cdecker> Anyway, I don't want to be the only one holding this up, so I'll shut up if the rest is happy with having TLV-types context dependent xD
19:31:45 <roasbeef> idk a namespace per message means we don't need to worry about global collisions, pretty nice mio
19:31:49 <roasbeef> imo
19:31:54 <t-bast> great, so sounds like we have an ACK on this PR and can move the next topic, thanks for the review
19:32:17 <t-bast> #action t-bast give a few days for other people to potentially chime in on Github, then merge 714
19:32:37 <t-bast> #topic networks in init message
19:32:40 <t-bast> #link https://github.com/lightningnetwork/lightning-rfc/pull/682
19:32:54 <t-bast> This is an old one, I believe c-lightning and eclair already support it
19:33:07 <t-bast> I don't think anything is holding up the merge on that one, right?
19:34:13 <roasbeef> iirc there some was some interop thing
19:34:21 <roasbeef> which seems to be settled now?
19:34:30 <t-bast> yep I tested interop
19:34:45 <t-bast> with c-lightning and lnd, correctly ignored by lnd, correctly handled by c-lightning
19:35:04 <roasbeef> cool, yeh duno when we'll impl it as we don't really have a strong need, since we don't support liquid or anything like that
19:35:29 <roasbeef> did we resolve the partial interesction thing?
19:35:33 <t-bast> no rush IMO
19:35:36 <roasbeef> so if some chains are shared but not all
19:36:09 <cdecker> Yes, c-lightning now checks against all the provided chains (https://github.com/ElementsProject/lightning/pull/3371)
19:36:18 <rusty> roasbeef: yeah, that was a coding bug in c-lightning, long fixed.  IMO, this is mainly to stop testnet connecting to mainnet etc.
19:36:34 <t-bast> this is ok I believe, the last requirement in Bolt7 says you'd only forward gossip for the supported chains
19:37:19 <roasbeef> lgmt'd on pr
19:37:31 <t-bast> good, let's move on
19:37:42 <t-bast> #action rebase and merge 682
19:37:59 <t-bast> #topic a home for Bolts
19:38:05 <t-bast> #link https://github.com/lightningnetwork/lightning-rfc/pull/738
19:38:31 <t-bast> This is a proposal to use the ln.dev DNS to host a gitbook for the spec
19:38:35 <cdecker> Seems we get more and more pseudonymous contributors :-)
19:38:48 <roasbeef> but then who manages the domain? also $900/yr? lol
19:39:24 <cdecker> Yeah, it'd be good if we can at least guarantee it doesn't morph into an altcoin site as soon as we have linked it extensively
19:39:47 <t-bast> at least accepting the gitbook part should be a no-brainer IMO (what the PR does)
19:39:47 <cdecker> We're need to have control over the domain before we can make this kind of committment
19:39:57 <cdecker> Oh yes, that part is good
19:39:58 <rusty> roasbeef: Yeah, ouch, but cdecker's point too.
19:40:15 <BlueMatt> how does one generate the resulting website? if its something simple I can also host on a dfferent domain
19:40:19 <BlueMatt> (eg ln.bitcoin.ninja or so)
19:40:21 <roasbeef> seems the PR is really just a table of contents?
19:40:29 <roasbeef> and the person is free to host it on gitbook if they want
19:40:44 <t-bast> I think generating the gitbook is really simple (probably just a JS library or something)
19:40:59 <roasbeef> so we should discuss the table of contents rather than gitbook itself
19:41:03 <BlueMatt> right, I can buy another server and sync it over to my webhost....
19:41:11 <rusty> Yes, I think we accept the book part, and I can take over the domain.  My BTC tipjar has enough for a few years, maybe more if Number Go Up.
19:41:22 <BlueMatt> that sounds good.
19:41:25 <t-bast> rusty: that's a great idea
19:41:45 <cdecker> We should contact the contributor soon though, since he mentioned 10 days ago that renewal is due in 14 days :-)
19:41:54 <t-bast> so on the table of content and links themselves, is there something we want to change from what's in the PR?
19:42:10 * BlueMatt notes that domain may be a waste of money.....
19:42:16 <cdecker> LGTM
19:42:27 <BlueMatt> pr itself LGTM
19:42:54 <roasbeef> the hosting/domain isn't really the important part, idk if you can generate it manually anymore (the gitbook), iirc you gotta do it all thru their interface now, could be wrong tho
19:43:05 <niftynei> anyone can host this , right?
19:43:11 <roasbeef> yeh
19:43:16 <roasbeef> doesn't this conflict w/ bolt #0?
19:43:26 <roasbeef> which already has a rough table of contents, or does the tool need an explicit summary.md?
19:43:59 <t-bast> I think the tool needs it to be in summary.md, let's check
19:44:08 <niftynei> based on the website structure, i'm going to guess it needs it for creating the sidebar
19:44:31 <t-bast> https://github.com/GitbookIO/gitbook/blob/master/docs/structure.md
19:44:37 <t-bast> yep it needs to be in SUMMARY.md
19:44:40 <rusty> I guess the q here is: are people broadly happy with me offering to take over the domain with my commitment to keep for at least 3 years?  (I'll ask him nicely if he'll sponsor it, too).
19:44:50 <t-bast> rusty: ACK
19:44:53 <cdecker> ACK
19:44:57 <roasbeef> t-bast: is that repo still being used? last commit 2 years ago, deprecation warning in the readme
19:45:18 <t-bast> arf, read too fast then, let's try to find the official doc
19:45:26 <cdecker> Well, doesn't have to be gitbook either, there are plenty of static site generators
19:45:52 <cdecker> We can work with that, but I think it might be really nice to have a canonical home for the spec that isn't the repo
19:45:56 <roasbeef> yeh, sub gitbook w/ any other static generator, don't think we really need "one to rule them all"
19:46:21 <t-bast> https://docs.gitbook.com/integrations/github/content-configuration#summary
19:46:24 <niftynei> i really like this but i don't understand why this particular user doesn't just use a fork of the repo?
19:46:28 <cdecker> And I quite like the domain, even though it's waaaaaay too expensive...
19:46:38 <roasbeef> perhaps let's move on? not super critical stuff here, just static site generation and hosting
19:47:13 <niftynei> it seems like they're asking for committee / community approval for a (admittedly very great) project where it doesn't exactly require it
19:47:19 <t-bast> Allright let's move on, I'll summarize
19:47:40 <roasbeef> niftynei: yeh, they could very well just fork add the summary and host it as they're doing rn
19:48:15 <t-bast> #action discuss with the OP the possibility of doing this in a fork of the repo
19:48:16 <t-bast> #action rusty to get in touch with OP about DNS hand-over
19:48:32 <t-bast> #topic Stuck channels
19:48:35 <t-bast> #link https://github.com/lightningnetwork/lightning-rfc/pull/740
19:49:19 <rusty> So we had m-schmoock demonstrate this with c-lightning, causing me to rush in a workaround for our (pending, cdecker niftynei ping) release.
19:49:33 <roasbeef> seems related to https://github.com/lightningnetwork/lightning-rfc/issues/745 ?
19:49:59 <roasbeef> this was always one of the most underspecified areas of the spec imo, just tons of edge cases waiting to be discovered
19:50:38 <rusty> There are two solutions I came up with:  the one I used was "if I'm the funder, keep an additional reserve to allow paying for another HTLC at current fees * 1.5".
19:50:52 <rusty> This is what c-lightning 0.8.1 does.
19:50:57 <roasbeef> just seeing this now, but why would the node do a fee increase that results in it not being able to pay for the set of preseent htlcs?
19:51:04 <joostjgr> Isn't the only thing that must be MUST is offering anything that would cause the chan to force close?
19:51:18 <BlueMatt> roasbeef: note that this is *unrelated* to update_fee - you can hit it without any fee changes at all
19:51:19 <joostjgr> keeping more reserve looks more like non-mandatory to me
19:51:23 <t-bast> roasbeef: it's not the node, it's the network :D
19:51:59 <rusty> roasbeef: yeah, funder can be forced to dip into reserves, even eliminate their output altogether if fees spike.
19:52:07 <joostjgr> nodes can keep safety margins as they like when sending out htlcs
19:52:15 <rusty> joostjgr: exactly.
19:52:25 <t-bast> joostjgr: true, this could be a SHOULD for that particular case (did I understand your comment correctly?)
19:53:09 <joostjgr> yes, could be something like SHOULD keep headroom for two htlcs. But there is a MUST directive in case the add would be guaranteed to kill the channel
19:53:19 <BlueMatt> lets just say MUST
19:53:29 <rusty> Anyway, the other mitigation would be to override the fundee side logic, which tries not to add an HTLC if the funder would not be able to afford the fee.  This would add a single-htlc carve-out for that case (i.e. fundee adds a single HTLC even if funder would be unable to afford fee).
19:53:35 <BlueMatt> i mean it kinda is - you MUST have available space for two more HTLCs, seems prefectly reasonable
19:53:36 <t-bast> but if we go in the direction of that extra reserve, and all impl behave the same way, what's nice is that we can know exactly how much we can send to the remote party; if we don't agree on the behavior, we can't know that we have to try, fail and adapt
19:53:41 <BlueMatt> with a note on the receive end that old nodes dont do this
19:54:21 <joostjgr> it is a protocol change if we make it MUST 2*, while otherwise we just define behavior that avoids force close that is currently happening
19:54:30 <roasbeef> t-bast: even w/ this stuff is still murky, giving yourself (and the other party) more "room" at all times kind of acknowledges this all isn't super well defined, so we'll all just try out best
19:54:46 <roasbeef> joostjgr: this pr itself is a protocol change technically
19:54:55 <BlueMatt> joostjgr: yes, it *should* be a protocol change
19:55:06 <joostjgr> i don't think it needs to be
19:55:12 <t-bast> roasbeef: it's not about being well-defined, it's because there's a condition where you could get stuck if the network fees rise, and that lets you avoid it
19:55:20 <joostjgr> if we just specify that nodes shouldn't offer updates that result in force close, i think that is enough
19:55:33 <BlueMatt> joostjgr: this doesnt result in force close
19:55:37 <rusty> Note that this is an unsolvable problem, because both sides can add htlc simultanously and always exceed the funders' affordable limits.  This is why they're heuristics.
19:55:40 <BlueMatt> it results in *stuck* channel
19:56:16 <joostjgr> if you add an htlc for which you can't pay the fee, it is force close, no?
19:56:20 <BlueMatt> right, to actually *solve* feerate would have to be charged to the side that added the htlc
19:56:33 <rusty> BlueMatt: indeed.
19:56:51 <BlueMatt> (which we should do eventually maybe, but that is a super separate discussion)
19:56:58 <t-bast> exactly, this is because of the assymetry between funder/fundee
19:57:13 <t-bast> but a short-term solution would be nice :)
19:57:18 <rusty> joostjgr: not in the spec, no.  That's true if funder adds something it knows it can't afford, but fundee could add at same time as funder (or, as funder changes fees, etc)
19:57:24 <BlueMatt> joostjgr: no. read the issue, functional bob will decide not to add any htlcs because its stuck
19:59:15 <roasbeef> t-bast: I mean that we're not really confident if this fixes "everyting", since this area generally isn't well defined
19:59:25 <rusty> I prefer the "fundee lets itself always have one HTLC even if funder can't afford it" because it doesn't limit channel capacity.
19:59:32 <rusty> roasbeef: it definitely doesn't fix everything.
19:59:53 <rusty> roasbeef: and it's perfectly well defined.  It's just not nice :)
20:00:06 <joostjgr> bluematt: i mean if the fundee adds something that funder can't pay for
20:00:16 <BlueMatt> joostjgr: right, but nodes wotn do that
20:00:26 <rusty> BlueMatt: how can they avoid it?
20:00:40 <rusty> BlueMatt: simultanous HTLCs in both directions can happen.
20:00:59 <t-bast> roasbeef: it's true that there are issues with the protocol itself because fee handling can't be perfect at the moment...but that additional restriction seems to fix quite easily an issue we're seeing in the wild. You could argue that implementations can do that mitigation without it being in the spec, is that what you mean?
20:01:02 <BlueMatt> right, in theory you could hit it (though joostjgr's propose change doesnt resolve this), but you can also hit this bug without that
20:01:36 <t-bast> rusty: but in that solution the funder can lose money in extreme cases
20:01:39 <rusty> BlueMatt: Yes, we seek to resolve the simple case, since it's acually happening.
20:01:44 <BlueMatt> right.
20:02:00 <BlueMatt> anyway, so it seems like most folks are on the same page - we should review the pr and merge it?
20:02:10 * BlueMatt has been slacking on it, sorry
20:02:17 <joostjgr> yes, those race conditions are unsolved. my comment was about MUST 2*. If it is MUST, shouldn't there also be a corresponding MUST on the receiver side specified?
20:02:34 <joostjgr> otherwise I think it should be SHOULD on the sender
20:02:34 <BlueMatt> joostjgr: no, there can't, cause old nodes dont implement it
20:02:45 <rusty> t-bast: I don't see how funder could lose money?
20:02:56 <t-bast> for the reason matt mentions, we can't put it on the receiver at the moment
20:02:57 <BlueMatt> we can totally add a sender-side "MUST, going forward" without a recipient-side check
20:03:26 <joostjgr> Also, hard coding the 2x doesn't sounds good to me. Implementations can make their own decision here. I find MUST too strong
20:03:32 <BlueMatt> this is definitely an important enough thing for  MUST
20:03:39 * cdecker is very much looking forward to externalizing fees altogether :-)
20:03:53 <BlueMatt> cdecker: note that that does not fully solve this problem.
20:04:02 <BlueMatt> 2x is a trivial headroom, I see no reason to not MUST it - if nodes want to do *more* they can
20:04:06 <BlueMatt> thats totally local policy
20:04:06 <t-bast> rusty: because that situation happens when the funder doesn't have funds on his side: if the fundee does send an HTLC that leaves the funder unable to pay for the fee, once the htlc fulfills the fundee can simply not sign the new commitment, broadcast the one with the HTLC on-chain, and race for the timeout
20:04:25 <t-bast> rusty: in case this is really because of a big fee raise, that on-chain timeout is possible
20:05:14 <joostjgr> btw, if the fundee sends dust htlcs, it is ok. don't know if we want to specify that too. it is sort of implicit in 'cannot pay for in the commitment', but could be good to make explicit
20:05:19 <t-bast> joostjgr: what's nice with all implementations sharing the same factor is that it's easy to know how your remote will behave
20:05:28 <rusty> t-bast: this is always true, even without this?  Either the fees are ludicrous, or the reserves were too low.
20:05:49 <t-bast> rusty: but you can't use the reserve to pay for the fee, can you?
20:05:55 <rusty> t-bast: yes.
20:06:14 <rusty> t-bast: it usually only happens when there's a race where both sides add though.
20:06:33 <t-bast> rusty: I need to refresh my memory there then, I'll have a look at it tomorrow
20:07:13 <rusty> (Originally we had language which would pull fees from the *fundee* side if they still weren't met after the funder's funds were exhausted, but this was seen as too ugly).
20:07:59 <rusty> t-bast: the only reason I didn't implement that mitigation is that I wasn't sure how impl did this in practice, since it's rare.
20:08:08 <t-bast> I think I need to dig more into it, shall we keep discussing this on Github and move on to next topics?
20:08:17 <roasbeef> fees are hard mayne
20:08:46 <roasbeef> i think it's something we all underestimated initially, just making it one sided (funder pays) seemed to have slashed off enough funny biz at the time
20:09:06 <BlueMatt> fees suck. lets get rid of them :)
20:09:26 <roasbeef> just gimmie a grant, i'll take care of the rest
20:09:47 * BlueMatt -> lunch.
20:10:17 <t-bast> I think we should disucss a bit of long term updates
20:10:32 <t-bast> Rusty do you want to talk about your event tests, or should I do decoy/rendezvous?
20:11:00 <rusty> t-bast: decoy!  Event tests need some attention from me and niftynei....
20:11:00 <t-bast> #action keep exploring solutions to stuck channels, discuss on Github
20:11:17 <t-bast> ACK, I'll do the talking then :D
20:11:27 <t-bast> #topic Decoy node_ids and poor man rendezvous
20:11:47 <t-bast> #link https://gist.github.com/t-bast/9972bfe9523bb18395bdedb8dc691faf
20:11:56 * BlueMatt will read scrollback later, but notes that he prefers to see more work on redezvous before trampoline. cc cdecker
20:12:25 <t-bast> The idea started from wanting wallets to be able to hide their node_id and scid when generating invoices
20:12:45 <t-bast> And do that without the need for a stateful protocol, just with crypto tricks
20:13:06 <t-bast> I wanted to explore that as far as I could, and it turns out (unless I'm missing something) that it can be used for a cheap rendezvous scheme
20:13:09 <roasbeef> first time looking at it, but at a glance looks pretty involved, would think there's something simpler that achives the same end result (ofc first time i'm seeing this)
20:13:27 <roasbeef> does it support actually giving errors back to the sender if they originate in the latter part of the route?
20:13:36 <t-bast> roasbeef: if you have something simpler, then it would be nice, do share!
20:13:48 <t-bast> roasbeef: define "latter part"?
20:13:51 <cdecker> roasbeef: yes, you just follow HTLCs back upstream
20:13:56 <roasbeef> the part not known to the sender
20:13:58 <cdecker> Like we do today
20:14:04 <t-bast> yes you could have errors there
20:14:21 <roasbeef> not following, so the same shared secret is used throughout the entire route?
20:14:31 <t-bast> but that's where the current attack I have lies: if nodes on the rendezvous path start giving accurate errors, mallory can probe the route via channel fees
20:14:41 <t-bast> roasbeef: yes, same shared secret here
20:14:55 <t-bast> the sender constructs a fully normal onion
20:15:01 <cdecker> t-bast: that's for the poor-mans rv only though
20:15:02 <t-bast> it's just using many routing hints
20:15:16 <t-bast> cdecker: yes, only for this specific proposal
20:15:27 <cdecker> Fully fledged RV with the sphinx onion construction is opaque if the error happens after the RV node
20:15:57 <cdecker> Wouldn't it be more accurate to call this a pseudonymous routing rather than rendezvous?
20:16:09 <t-bast> cdecker: yes, fully fledged RV also avoids any kind of probing, but may be very costly in terms of space in invoices
20:16:15 <roasbeef> it's basically like blinded hop hints?
20:16:24 <t-bast> totally, this is really pseudonymous and not rendezvous
20:16:40 <t-bast> roasbeef: exactly, you simply blind nodes and scids after the "RV node"
20:17:05 <t-bast> the issue is that it means sender can try that route with many different fees
20:17:16 <t-bast> and that may help him uncover the real channels and nodes
20:17:28 <t-bast> I'm not sure yet how to best address that
20:17:35 <cdecker> Agreed on the space savings in the invoices, full-fledged RV is doing very poorly there :-(
20:18:20 <t-bast> I was starting from the assumption that full-fledged RDV was not possible because of the space cost; but maybe that assumption was flawed
20:19:27 <rusty> t-bast: you can tell a tmp scid is being used, but we'd have to define exactly what that effects.
20:19:35 <rusty> s/effects/affects/
20:19:47 <cdecker> It might be quite expensive, but we can do with a couple of hops, (~65 bytes per hop after the RV node). We should be able to fill the back of the onion in using a PRNG (chacha20)
20:20:08 <cdecker> Sphinx RV is what I mean here
20:20:18 <t-bast> rusty: yes, that definitely deserves more thinking, it's still an early proposal
20:20:34 <t-bast> cdecker: that means you'd be able to put less than 1300 bytes in the invoice?
20:20:49 <cdecker> Yes, that's what I'm thinking
20:20:50 <t-bast> cdecker: by somehow sharing the "mid-state" of the onion encryption?
20:21:09 <t-bast> Do you have drafts on how we could do that?
20:21:19 <cdecker> Not yet, but I'm working on it
20:21:45 <cdecker> The trailer generation just needs to change slightly so it can be generated at the sender
20:22:15 <t-bast> Nice, I think it's worth putting some effort in that direction
20:22:18 <rusty> I really want a system which can be used both for simple private channels and fully private routes.
20:22:19 <roasbeef> even sphinx RV leaves a lot to be desired
20:22:35 <roasbeef> as it only packs a single route, and how many payments work with just one single golden route? also what about payment splitting
20:22:54 <cdecker> Right, that's indeed an issue
20:23:05 <t-bast> rusty: yes, if we had that sphinx rv we could use it from a mobile with only one-node, and that would hide your node_id and scid, that would be great
20:23:19 <t-bast> roasbeef: we'd need to provide more than one of those
20:23:27 <roasbeef> how many....? ;)
20:23:27 <t-bast> simply because of MPP if you want to do a big payment
20:23:38 <t-bast> so it really needs to be somewhat space efficient
20:23:49 <roasbeef> idk feels like a dead end given new considerations
20:23:56 <t-bast> or we should work on a different encoding for invoices, more compact :D
20:24:15 <t-bast> what does feel like a dead end?
20:24:24 <t-bast> my decoys or full sphinx rdv?
20:25:17 <roasbeef> sphinx based rdv, haven't read this decoy thing yet but if it also relies on a set of pre-planned routes same may apply /shrug
20:25:55 <t-bast> I don't know, it depends on how much space we can still use in invoices
20:26:10 <cdecker> The decoy IDs retain their usefullness for the last few hops, I just wouldn't extend it beyond that. Let's keep em as a sort of blinded routehint
20:26:13 <roasbeef> in the OG hornet setting or even tor, the problem is simpler as you just want a path and you don't have as many constraints as we do in the network, so you can just create a hand full of them (circuits) and they'll work for just about anything
20:26:21 <cdecker> That should make discussion more focused
20:27:25 <t-bast> let's say we're using these decoys for only a few hops indeed, not as a full rendezvous
20:27:58 <t-bast> the issue is that we need support from both sender and the last hops' nodes, so it needs to bring enough features for implementations to all agree to implement and ship
20:31:32 <rusty> t-bast: come for the blinding, stay for the fact that we add feature flags to routehints!
20:31:57 <t-bast> that can be a first sell ;)
20:32:51 <t-bast> I think it's somewhat simple to implement, but we need to have enough people review the crypto and implementations ACK to make sure it can ship in wallets
20:33:52 <t-bast> I'll have to leave in a few minutes, shall we wrap it up and keep discussing that on the mailing list and github?
20:34:22 <t-bast> We had to skip over two PRs, feel free to review them on github so we can merge them next time ;)
20:35:22 <cdecker> Same here, it's getting late :-)
20:35:32 <joostjgr> One final comment from me on anchors: Last meeting we decided to drop the symmetric csv because it wasn't a complete fix for the gaming issue. That left us with two options to proceed, from which we made a preliminary decision. Please check out the PR to comment. We are planning to merge the new format with an experimental feature bit in the next release.
20:36:15 <t-bast> joostjgr: sounds good, let's discuss that on Github
20:36:39 <t-bast> #action look at latest developments on anchor outputs PR
20:36:59 <t-bast> #action cdecker to investigate full sphinx rendezvous possibilities
20:37:25 <t-bast> #action tear decoys proposal apart on github until we're satisfied
20:37:57 <t-bast> #endmeeting