--- Log opened Mon Mar 01 00:00:43 2021
00:10 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #lightning-dev
00:25 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 245 seconds]
00:29 -!- belcher [~belcher@unaffiliated/belcher] has joined #lightning-dev
00:42 -!- dergoegge [sid453889@gateway/web/irccloud.com/x-vpggjtvyxjofpnen] has joined #lightning-dev
00:48 -!- laptop [~laptop@ppp-2-161.leed-a-1.dynamic.dsl.as9105.com] has joined #lightning-dev
01:00 -!- riclas [~riclas@77.7.37.188.rev.vodafone.pt] has joined #lightning-dev
01:18 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has quit [Ping timeout: 245 seconds]
01:30 -!- musdom [~Thunderbi@202.184.0.102] has joined #lightning-dev
01:35 -!- Emcy [~Emcy@unaffiliated/emcy] has quit [Remote host closed the connection]
01:35 -!- Emcy [~Emcy@unaffiliated/emcy] has joined #lightning-dev
01:37 -!- __gotcha [~Thunderbi@plone/gotcha] has joined #lightning-dev
01:38 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 240 seconds]
01:41 -!- jonatack [~jon@37.173.106.99] has joined #lightning-dev
01:54 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Ping timeout: 268 seconds]
01:54 -!- belcher [~belcher@unaffiliated/belcher] has joined #lightning-dev
02:04 -!- kexkey [~kexkey@static-198-54-132-105.cust.tzulo.com] has quit [Ping timeout: 260 seconds]
02:46 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #lightning-dev
04:17 -!- pm7_ [pm7@gateway/shell/mydevil.net/x-nkiwqjagpdxxnpsg] has quit [Read error: Connection reset by peer]
04:17 -!- pm7 [pm7@gateway/shell/mydevil.net/x-vncspagtycinfktl] has joined #lightning-dev
04:31 -!- musdom [~Thunderbi@202.184.0.102] has quit [Ping timeout: 245 seconds]
04:37 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 264 seconds]
04:44 -!- cryptosoap [~cryptosoa@gateway/tor-sasl/cryptosoap] has quit [Remote host closed the connection]
04:45 -!- cryptosoap [~cryptosoa@gateway/tor-sasl/cryptosoap] has joined #lightning-dev
04:47 -!- musdom [~Thunderbi@202.184.0.102] has joined #lightning-dev
05:13 -!- kloinka [~quassel@223.177.233.220.static.exetel.com.au] has quit [Quit: No Ping reply in 180 seconds.]
05:15 -!- kloinka [~quassel@223.177.233.220.static.exetel.com.au] has joined #lightning-dev
05:19 -!- kloinka [~quassel@223.177.233.220.static.exetel.com.au] has quit [Client Quit]
05:20 -!- kloinka [~quassel@223.177.233.220.static.exetel.com.au] has joined #lightning-dev
06:07 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #lightning-dev
07:01 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 260 seconds]
07:25 -!- vtnerd [~vtnerd@50-82-248-114.client.mchsi.com] has quit [Ping timeout: 265 seconds]
07:53 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #lightning-dev
08:41 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Ping timeout: 240 seconds]
08:48 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 260 seconds]
08:52 -!- vtnerd [~vtnerd@50-82-248-114.client.mchsi.com] has joined #lightning-dev
09:06 -!- queip [~queip@unaffiliated/rezurus] has joined #lightning-dev
09:36 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has joined #lightning-dev
09:47 -!- foxp2 [~foxp2@ec2-54-221-232-236.compute-1.amazonaws.com] has joined #lightning-dev
09:47 < foxp2> hey all, quick q is HODL invoices the only way one can `cancel` or `delete` an invoice?
09:47 < foxp2> (on LND) **
09:58 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has quit [Read error: No route to host]
10:00 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has joined #lightning-dev
10:20 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Remote host closed the connection]
10:20 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #lightning-dev
10:25 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 245 seconds]
10:26 -!- joost [~joostjgr@81-207-149-246.fixed.kpn.net] has joined #lightning-dev
10:47 -!- t-bast [~t-bast@5.51.245.138] has joined #lightning-dev
10:56 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev
10:57 -!- bmancini55 [8ff42f6a@143.244.47.106] has joined #lightning-dev
11:00 < rusty> Hello everyone!
11:00 < t-bast> Good morning everyone!
11:02 < cdecker_> Good evening everybody :-)
11:02 -!- cdecker_ is now known as cdecker
11:02 < bitconner> hello 👋
11:03 < cdecker> Bot is still not up, turns out it is a bit quirky to set up, sorry :-(
11:03 < jkczyz> hey
11:03 < t-bast> no worries, we've managed without the bot so far ;)
11:05 < t-bast> Does someone want to chair? We had an interesting discussion with joost on the agenda issue (https://github.com/lightningnetwork/lightning-rfc/issues/850), I want to stress again that I don't want the agenda I *propose* to be set in stone, anyone should really challenge it and say if there's a topic they'd like to see covered
11:06 < t-bast> And we're free to re-arrange the order I set, I don't want to lock in something, I want it to be useful to most people
11:06 -!- mode/#lightning-dev [+o rusty] by ChanServ
11:06 -!- mode/#lightning-dev [+v lightningbot] by rusty
11:07  * t-bast watches in awe as rusty is doing IRC magic
11:07 < niftynei_> hello hello
11:07 -!- niftynei_ is now known as niftynei
11:07 < t-bast> Hey niftynei! Power's back it seems? :)
11:08 < niftynei> Yeah, it's back on !
11:08 <@rusty> #startmeeting
11:08 <@rusty> ...
11:08 <@rusty> :(
11:08 < cdecker> Yeah, sorry. Supybot is a bit quirky to setup :-(
11:09 <@rusty> #action Rusty to ping aj about the bot when it's his daytime...
11:11 <@rusty> OK, let's start minus bot.  Who is chairing?
11:12 < t-bast> I can chair if you want
11:12 < t-bast> The PR list I setup should be quite quick
11:12 < t-bast> I believe we should have time for the long term stuff and we'll poll the audience to choose which one(s)
11:13 <@rusty> Ack #839, seems simple and good.
11:13 < t-bast> #topic https://github.com/lightningnetwork/lightning-rfc/pull/839
11:13 < t-bast> This PR simply sets the funding expiry explicitly to 2016 blocks
11:14 < cdecker> Nice and simple, I like it 👍
11:14 < t-bast> We defer the "so long and thanks for all the sigs" mode for later, I'd love to have a feature bit named like that :D
11:14 < cdecker> I'll draft it up, and look into what the minimal set of information to keep around is
11:15 < t-bast> bitconner, what do you think of this simple suggestion from lnd's pov?
11:16 < niftynei> (+1 from me fwiw)
11:16 < bitconner> t-bast: lgtm, lnd will forget channels after 2016 blocks so this it is backwards compatible with our timeouts
11:17 < bitconner> (as the fundee)
11:17 < t-bast> great, you don't even have anything to implement then!
11:17 < bitconner> hehe ;)
11:17 < t-bast> except maybe a CPFP for the funder's point of view, but it can be manual for now
11:17 < t-bast> #action Merge #839
11:18 < t-bast> #topic Signest prefix for Bolt 11 invoices
11:18 < t-bast> #link https://github.com/lightningnetwork/lightning-rfc/pull/844
11:18 <@rusty> bitconner: I like spec compliance before the spec is even written. Proves our God-like foresight powers...
11:18 < bitconner> i believe that is already possible via our cpfp engine, but it isn't done automaticaly
11:18 < bitconner> sometimes it's easier to write the code first, then write the spec xD
11:19 < t-bast> We haven't had time to do anything signet-related for eclair, so I don't have a strong opinion on #844 but it seems reasonable
11:19 <@rusty> bitconner: no, I'm going with spooky foresight.  Damn your prosaic explanations!
11:19 <+roasbeef> yep users can use cpfp to bump up funding in lnd, assuming they didn't use psbt to produce no change output 
11:20 < t-bast> :+1:
11:20 <@rusty> t-bast: yeah, the signet-same-prefix thing is just kinda nasty.  The fact that there are N signets is kinda an issue too, ofc.
11:21 <@rusty> But fundamentally they chose this confusion deliberately AFAICT?
11:21 <@rusty> (Bitcoin addresses already have this issue, and they like it?)
11:21 < bitconner> rusty: 👻🔮
11:21 < t-bast> you mean between different signets or between signet and testnet?
11:22 < t-bast> looks like it's between testnet and signet from the bitcoin address' pov
11:22 < bitconner> probably depends on whether you're in the testnet-is-dead camp or not
11:23 < bitconner> i'd support having a distinct prefix for ln tho
11:23 <@rusty> bitconner: ah, that makes more sense.  But we could do something FU like "hrp is the hex encoding of the genesis block with 1s turned into ls" :)
11:24 < bitconner> lolol that's one way to remove all ambiguity, until signet-cash comes along :)
11:24 < cdecker> Then we just use the blockchain head, and your invoices are valid only 10 minutes in expectation xD
11:24 < t-bast> genesis-block re-use is going to become a thing
11:25 < cdecker> Anywho, do we care if signets clash?
11:25 < t-bast> I don't
11:26 < t-bast> I think the PR's proposal is reasonable: we distinguish signet from testnet (just because we can, and it's simple), but we don't do anything fancier
11:26 < cdecker> I'm a bit on the edge, going directly against core on this, but I think making unique prefixes would be nice
11:27 < bitconner> does anyone know the reason they went with the same prefix? maybe hw wallet support?
11:27 < bitconner> which would be a problem we are free of since i'm not aware of any hw lightning wallets atm
11:28 <@rusty> bitconner: the only thing I could find was an "all testnets" argument.  Which, given regtest, kinda makes sense I guess?  (Note: bolt12 invoices fix this properly, as in there's a TLV for the chainid with the default being mainnet).
11:29 < t-bast> in that case, since LN chose to distinguish regtest from testnet, it would make sense to distinguish signet as well, wouldn't it?
11:30 <@rusty> But I'm happywith 'lntbs' ?  Anyone have any pref?
11:30 < t-bast> I think bitconner's point makes sense for bitcoin, to have existing wallets work without any update, but I don't think that's an issue we have for LN testnet wallets
11:30 < t-bast> 'lntbs' looks fine to me as well
11:31 < bitconner> tbs vs tb is a little close just on sight, but idk how many people are really visually inspecting prefixes
11:32 < bitconner> +1 for 'lntbs'
11:32 <@rusty> lnsig seems like it's something else, so yes, +1 for lbntbs
11:33 < t-bast> did you really mean lbntbs or did you mean lntbs rusty?
11:35 < bitconner> prob typo?
11:35 -!- EndFiat [EndFiat@gateway/vpn/mullvad/endfiat] has quit [Ping timeout: 264 seconds]
11:35 < t-bast> I guess so, let's go with that and merge the PR, sounds like we have an agreement
11:35 <@rusty> Oops, yes!  Acked lntbs on the PR.
11:35 < t-bast> #action merge #844
11:35 < t-bast> #topic Closing fee requirement
11:35 < t-bast> #link https://github.com/lightningnetwork/lightning-rfc/pull/847
11:36 < t-bast> I've noticed that we previously had a requirement that mutual close had to propose a lower feerate than the current commit tx feerate
11:36 < t-bast> This doesn't make sense anymore for anchor outputs, where we may keep the commit tx feerate artificially low
11:36 < t-bast> So this PR simply removes that requirement
11:36 < cdecker> Good find!
11:37 < t-bast> I think it was unnecessary to be that strict for non-anchor outputs channels, so I simply removed it instead of changing it to "if not anchor outputs ..."
11:38 <@rusty> I think it is a MUST.  The idea is that it is always better than a unilateral close (even if only because fee is same and no delays).
11:39 < bitconner> makes sense to me, i think before we also used this as a heuristic to not accept crazy fee proposals tho
11:39 < darosior> cccccctbbtnrggnjtnfjrfbhdjbhlljvckdcfidnbhdi
11:39 <@rusty> But we should explicitly say that it's not true for anchor featuress.
11:39 <@rusty> Hello to darosior's cat.
11:39 < t-bast> hello to darosior's yubikey xD
11:39 < darosior> sorry about that, yubikey ^^
11:40 < bitconner> hello to darosior's cat's yubkey!
11:40 < darosior> x)
11:40 < t-bast> rusty: IIUC you'd like to keep the existing MUST, and only relax it for anchor outputs?
11:41 -!- EndFiat [EndFiat@gateway/vpn/mullvad/endfiat] has joined #lightning-dev
11:41 <@rusty> t-bast: yeah.
11:41 < bitconner> perhaps we want to recommend: "shouldn't be more than X*what-your-fee-estimator-says"
11:41 < bitconner> o/w it is very easy to just burn everything to fees if no check is performed
11:41 < t-bast> My point is that it's unnecessary, you can have your side accept the remote fee and propose something smaller, and if at the end you still disagree you'll force-close
11:42 < t-bast> So no need for a MUST from the start, right?
11:42 <@rusty> t-bast: we want it to succeed, and prior to anchor outputs there was no reason to allow this.
11:42 < t-bast> As long as you don't sign a feerate that's higher than your higher bound you're ok, and that's entirely a local decision isn't it?
11:43 <+roasbeef> change here is to just use the same fee rate? 
11:43 <+roasbeef> on the commitment, and disallow going lower? 
11:43 < bitconner> good point, yes that's true
11:43 < t-bast> Ok, I can change that to only relax for anchor outputs, that works for me as well
11:44 <@rusty> t-bast: I think for anchor outputs we're not bound by anything other than the actual minimum possible; there's no obv upper bound.
11:44 < bitconner> depending on how everyone's fee negotiation is implemented, you may not ever converge on an acceptable value however
11:44 <@rusty> Say 253 sat/ksipa.
11:44 < bitconner> if both parties are being stubborn
11:44 < t-bast> alright I'll udpate the PR to only relax this for anchor outputs then, this way it's backwards-compatible
11:44 < cdecker> Only allowing for anchor outputs avoids nasty surprises when deploying as well
11:44 < t-bast> #action t-bast to update the PR to relax only for anchor outputs
11:45 < t-bast> #topic Wording clarification around preimage reveal attack
11:45 < t-bast> #link https://github.com/lightningnetwork/lightning-rfc/pull/848
11:46 < t-bast> This is a wording clarification, but this thing is subtle, it's really hard to get right IMO
11:46 < t-bast> bitconner: right, that depends on the algorithm right now, so better be safe and keep the non-anchor outputs unchanged
11:48 <@rusty> Yeah, I updated our impl and noted this conflicting requirement.  Some rewording needed, but there are multiple options.  Perhaps we ack in principle and sort out the details on the issue?
11:49 < t-bast> ACK, let's bikeshed on the PR?
11:49 <@rusty> (I like all the suggestions, but they need to be merged into one change)
11:49 -!- EndFiat [EndFiat@gateway/vpn/mullvad/endfiat] has quit [Ping timeout: 240 seconds]
11:50 < t-bast> Great, let's move on then
11:50 -!- musdom [~Thunderbi@202.184.0.102] has quit [Ping timeout: 245 seconds]
11:50 < t-bast> #action bikeshed on the PR
11:50 < t-bast> #topic Clarify nonce size
11:50 < t-bast> #link https://github.com/lightningnetwork/lightning-rfc/pull/849
11:50 < t-bast> This one should be very simple
11:50 < t-bast> It just clarifies the nonce size we use
11:50 < cdecker> Yep, my bad for assuming it'd be 64bits everywhere, no objections to the change 👍
11:51 <@rusty> Ack!  Yeah, the 96 came later (with the RFC standardization process IIRC).
11:51 < t-bast> Interestingly our library does require us to provide 96 bits, and it startled me a bit at first but I didn't dig deep
11:52 <+roasbeef> yeh iirc there's a few diff RFCs that use diff sizes 
11:52 < bitconner> ack 👍
11:52 < cdecker> Nice, that was a quick one ^^
11:53 < t-bast> Great!
11:53 < t-bast> #action merge #849
11:53 < t-bast> What long term topic would you like to discuss now?
11:55 <@rusty> Don't all speak at once!
11:55 < cdecker> Hm, undecided between trampoline and blinded paths :-)
11:56 < cdecker> Both are pretty late in their stage and would love to hear your experiences for trampolines for example (which ACINQ uses extensively iirc)
11:56  * t-bast hears a loud crowd yelling trampoline, is that only me?
11:56 <@rusty> t-bast: not just you :)
11:56 < cdecker> Trampoline sounds interesting ^^
11:56 < t-bast> On the trampoline side, Electrum has made a lot of progress recently implementing it
11:57 < t-bast> They have the wallet code complete
11:57 < t-bast> And are working on the node-relay part
11:57 < t-bast> They are going to ship a version of electrum wallet with trampoline support, but because the feature bit and onion error messages aren't locked in in the spec, they won't completely interoperate with eclair
11:58 < t-bast> I'm hoping we can get these locked in 2021 to allow wallet to interoperate in prod ;)
11:59 <@rusty> t-bast: yes, what needs doing there exactly?  Having incompat deployments is a big fail 
11:59 < cdecker> I'm pretty sure we could implement the forwarding part purely as a plugin, would be like rusty's bounce but ad-hoc ^^
12:00 < t-bast> To unblock mainnet deployments, we'd to merge in the spec: 1) the feature bits used 2) the new TLVs used in Bolt 4 and 3) the new Bolt 4 error messages
12:00 < t-bast> That would provide a good basis for a first E2E deployment, and we could add more features later (integration with offers for example)
12:01 <@rusty> t-bast: OK, feature bits are the most obv bottleneck.  We used to have a waiting room; we're currently having a few pending ones.
12:01 <+roasbeef> t-bast: it would be a distinct doc though as is now right? as imo it's useful to have the overview and independent context, vs just shoving things into the main doc using what is essentially a series of if/else statements 
12:01 -!- jonatack [~jon@37.173.106.99] has quit [Ping timeout: 264 seconds]
12:01 < t-bast> It's mostly what's in this PR: https://github.com/lightningnetwork/lightning-rfc/pull/836
12:01 <+roasbeef> are electrum clients actually routing nodes though also? 
12:02 <+roasbeef> I was under the impression they already delegate forwarding/path finding in their current arch?
12:02 < t-bast> electrum wallet don't route AFAIK, but electrum desktop does IIRC
12:02 < t-bast> but I'm not 100% sure about the electrum desktop part
12:02 <@rusty> (Is everyone OK if I add feature numbers to the titles of PRs, where they exist, so we can see them at a glance on https://github.com/lightningnetwork/lightning-rfc/pulls ?
12:02 <+roasbeef> there's a difference? 
12:03 <+roasbeef> ah you mean electurm server vs electurm wallet? 
12:03 < t-bast> right, electrum server sorry
12:03 < t-bast> rusty: ACK
12:03 < cdecker> ack
12:03 < t-bast> roasbeef: but I'm not sure exactly how you configure it to enable lightning TBH
12:04 <+roasbeef> gotcha, I was under the impression they were mostly wallet clients, also just given all the DoS n stuff that goes on w/ electurm servers and that on going scam, etc 
12:05 <+roasbeef> iirc there's like 50 servers world wide or something like that 
12:05 <+roasbeef> which doesn't include electrum x ? 
12:06 <+roasbeef> if this is the case, then for them it really isn't much diff than just delegating path finding right? 
12:06 -!- EndFiat [EndFiat@gateway/vpn/mullvad/endfiat] has joined #lightning-dev
12:06 <+roasbeef> since the server knows the true destination 
12:06 < t-bast> roasbeef: no, that's why they'd like to have parts of trampoline standardized, because that way we can do multiple trampoline hops
12:07 < t-bast> and in that case trampoline nodes can't unmask the sender/recipient
12:07 <+roasbeef> well you still leak additional info, since there's a restricted path the route can go on if most nodes aren't also on it 
12:07 < t-bast> especially if the trampoline route can be electrum -> some eclair -> another electrum -> another eclair or something like that
12:08 <+roasbeef> have y'all done tests in teh wild with multiple hops to get a better feel for the impact re latency/fees/tiemlock? 
12:08 < t-bast> roasbeef: what do you mean about the additional info?
12:08 <+roasbeef> I mean if there's two trampoline nodes, and they're hte next hop, I have a smaller set of possible paths I need to analyze fromthere 
12:09 <+roasbeef> but that's a side point really, mainly that it won't neccersily mean better privacy 
12:09 <+roasbeef> necessarily* can't type as usual 
12:09 <+roasbeef> don't want to side track this tho as these points have been raised in teh past 
12:10 < ariard> hello
12:10 < t-bast> I'm not sure I understand why it necessarily means it's worse privacy either...
12:10 < cdecker> Yep, there is a clear tradeoff here, trampoline is more of a usability feature for light wallets that can't sync gossip in time to be useful, and we trade it in for potentially a bit more privacy leak
12:10 <+roasbeef> (last comment: if I get a trampoline packet, and the dest isn't another trampoline node, then I know that's the true dest) 
12:10 < cdecker> I think the current proposal disallows that
12:10 <+roasbeef> t-bast: see this example, simple naive 2 trampoline node topology) 
12:10 <@rusty> OK, feature bits added to titles.  Found a clash already, proposed a move ( joost's https://github.com/lightningnetwork/lightning-rfc/pull/814 )
12:11 <+roasbeef> orly? interesting
12:11 < t-bast> to be honest I haven't seen the worse privacy argument detailed and I believe it doesn't hold once at least a few nodes run it
12:11 < cdecker> i.e., it mandates the recipient must be a trampoline iirc
12:11 < t-bast> roasbeef: yes, that has been disallowed for more than a year :D
12:11 <+roasbeef> t-bast: well at a high level, if there're less possible paths, and less path diveristy, all the other leaks (time lock, etc) are compounded 
12:11 <@rusty> Yeah, we'll be trampolining by default I imagine.
12:11 < bitconner> given two paths of equal length, the one with trampoline hops has reduced privacy 
12:11 < t-bast> but there's more possible paths, not less
12:11 -!- jonatack [~jon@37.173.106.99] has joined #lightning-dev
12:12 < t-bast> I think you're not up to date with trampoline TBH
12:12 < t-bast> so we're kinda talking past each other and don't really understand each other's points...
12:12 < t-bast> thanks rusty for udpating the PR titles
12:13 < bitconner> how can there be more possible paths if they're the same length?
12:13 < t-bast> but why same length? I don't understand what you mean
12:14 < cdecker> There can be potentially much longer paths: each trampoline hop can in theory be 20 hops itself to reach the next one
12:14 < t-bast> with trampoline the lenght of the flattened route is not constrained to 20 hops if that's what you mean, that has been discussed on the PR
12:14 < bitconner> i'm just saying, if you compare a source routed path of length 10, and a trampoline routed path of length 10, the trampoline has less privacy bc itermediaries learn _more_ hops in the path other than incoming/outcoming like they would in source routing
12:14 < cdecker> Practically a sender can only do X * network diameter on purpose though (where X is max number of trampoline hops)
12:14 < t-bast> bitconner: but then again, trampoline has never had that restriction, I don't know where you read that...
12:15 < bitconner> idt it's a restriction? i'm just saying if you compare those two paths qualitatively?
12:16 < t-bast> but you can't "compare these two paths", that doesn't make sense...
12:16 < bitconner> why not? the path the htlc takes over the network, i.e. the final path taken by the htlc
12:16 < ariard> t-bast: IIRC you have also a concern if you cumulate MPP and trampoline, i.e intersection of incoming paths
12:16 < t-bast> you won't end up with the same paths when using trampoline and fully source routed, and you'll have even more randomness in the trmapoline one because you'll likely take detours because of your lack of knowledge of the graph
12:17 < t-bast> ariard: that's true but that's unrelated to trampoline, that's true of MPP regardless of trampoline
12:17 < t-bast> ariard: and it only lets you know who is the previous trampoline node, not whether it's the payer or not
12:18 < t-bast> ariard: so on that front trampoline makes it better than non-trampoline
12:18 < bitconner> t-bast: that's a pretty strong assumption no?
12:18 < ariard> t-bast: trampoline make it worst as mpp will likely happen few hops after sender
12:18 < t-bast> bitconner: what is?
12:18 < ariard> or are you going to make it mandatory to only trampoline with a minimal distance
12:18 < bitconner> > "you'll have even more randomness in the trmapoline one because you'll likely take detours" 
12:18 < t-bast> ariard: that's what will happen *most of the time*, but privacy-conscious wallet can very easily defeat that heuristic
12:19 < bitconner> the shortest path may be directly through trampoline nodes
12:19 < ariard> t-bast: well I mean only trampoline with at least 3 hops of distance, that way you have a minimal anonymous set
12:19 < t-bast> bitconner: yes, but it will more often not be than with the current source-routed path-finding algorithms
12:19 < ariard> don't trampoline with your LSP
12:20 < t-bast> bitconner: because since you have incomplete knowledge of the graph, your choice of trampoline nodes will have some randomness with regards to the payment you're making
12:20 < t-bast> ariard: exactly, trampoline with your LSP reveals you as a sender (but not who you're paying) and is your choice when you want to optimize cost instead of privacy
12:21 < t-bast> ariard: but trampoline doesn't require you to do that at all, and I expect wallets with different audiences or different user modes to flourish
12:21 < bitconner> imo it's difficult to conclude "there is no reduction in privacy" when there are cases where it does happen
12:21 < ariard> t-bast: yeah I just hope you will make it easy to opt-out for users who prefers to optimize for privacy
12:22  * BlueMatt still thinks this is a lot of effort to avoid 10ms and downloading 10MB of data
12:22 <+roasbeef> t-bast: isn't trampoline w/ LSP the default way it's used rn, and will also be in the future given the way electrum has clients connect out to their nodes? 
12:22 <+roasbeef> that's the way phoenix works rn iiuc 
12:22 < ariard> t-bast: I don't get the incomplete knowledge of the graph guarantee better privacy in the sense of higher randomness in trampoline selection
12:22 < bitconner> the point i was getting at earlier is in regards to quanitifying how much longer the path needs to be (also probably looking at fraction of trampoline nodes in the path) to arrive at similar privacy guarantees
12:22 < cdecker> Except it isn't 10ms on flaky mobile connections, and mobile is likely the largest number of dpeloyemnts we're going to see
12:22 < bitconner> i think it'd be difficult to quantify tho..
12:22 < t-bast> bitconner: I'm not saying that, as there are cases where source-routing can also leak a lot, I'm saying it can be used privately
12:23 < BlueMatt> cdecker: sorry, I meant 10ms as in the cost to run a route calculation
12:23 <+roasbeef> t-bast: but it's additive tho right? those constriants, but now within a more restricted overlay topology 
12:23 < t-bast> bitconner: as long as we've allowed nodes to deploy it
12:23 < BlueMatt> ariard: basically he's arguing that, if you have a trampoline route with 3 hops and a regular route with 3 hops, the trampoline route an intermediary learns less - a normal route you know that each hops ia a channel, but with trampoline each hop could be many channels.
12:23 < ariard> bitconner: if you assume longuer paths, your routing is more costly and in fine you're trading bandwidth/storage against sats, with a privacy leak...
12:23 < BlueMatt> ariard: so he's arguing its harder to infer the previous hop in a trampoline, though I'm not sure I need to think about it
12:23 < t-bast> But it's the same today: whenever you're on a mobile phone you will leak to the next node that you're the payer, regardless of trampoline
12:24 < t-bast> The only thing you can hope to hide is who the payee is
12:24 < t-bast> And trampoline with more than 1 hop does exactly that
12:24 <+roasbeef> there's leaking you're the payer, and leaking more information about the payee 
12:25 <@rusty> I think it's better than the status quo, which is why I'm supportive.
12:25 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #lightning-dev
12:25 <+roasbeef> BlueMatt: if the previous hop is one of 5 trampoline nodes, is it really harder? 
12:25 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Remote host closed the connection]
12:25 < t-bast> roasbeef: that's where I don;t see why trampoline leaks more than source routing today, whenever you use more than 1 trampoline hop
12:25 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #lightning-dev
12:25 < BlueMatt> roasbeef: eh, I was parroting the argument, honestly I dont *think* I buy it cause in practice you can maybe guess based on where you, the intermediary got it, but maybe not if you assume ~all nodes support trampoline
12:26 < ariard> BlueMatt: I'm not sure if it holds with the decreasing order of cltv delays
12:26 < bitconner> BlueMatt: the argument is really the opposite, with trampoline the intermediary learns more bc they learn an additional hop in the route that is not adjacent to them
12:26 < BlueMatt> right, I think an intermediary trampoline hop can likely maybe guess where the previous trampoline hop was, just like a payee can likely probably guess where the sender was today.
12:27 < BlueMatt> but maybe its harder.
12:27 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #lightning-dev
12:27 < BlueMatt> bitconner: but, I presume, there is no "that hop is closer to the target" heuristic possible, which is what you'd use to exploit it
12:27 <+roasbeef> yeh as ariard notes, there're other leaks like cltv delays, the "max" cltv limit, etc 
12:27 < BlueMatt> presumably, and I think the only reasonable way to do trampoline routing is, you'd just pick 3 random nodes, maybe 4 as your trampoline hops
12:27 < bitconner> BlueMatt: time locks?
12:27 < ariard> I agree with bitconner there, the additional hop your learn is likely to be closer in graph from final destination, compare to regular route
12:28 < BlueMatt> with no care for where they sit in the network.
12:28 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 276 seconds]
12:28 < t-bast> but we can work around these leaks exactly like we work around them for source-routing, trampoline doesn't do anything game-changing here
12:28 < BlueMatt> bitconner: yes, thats a major issue. We need to randomize those.
12:29 < t-bast> BlueMatt: yes, you'll pick only a few trampoline nodes in your route, and if picking randomly then you're defeating any heuristic looking at whether the route is "logical"
12:29 < bitconner> if i'm breez and i'm forwarding a trampoline to ACINQ with somewhat normal timelocks it's pretty safe to assume where that payment is going 
12:29 < bitconner> where as with source routing breez only learns the outgoing node
12:30 < ariard> bitconner: add some block noise, don't consume rawly routing node policy, that's obsvervable by anyone
12:30 < t-bast> bitconner: not at all: either one of the Phoenix wallets (today) which is one in thousands of nodes or any other node in the network if Acinq is not the last trampoline
12:30 < BlueMatt> t-bast: right, I think it would be wholly unreasonable to implement trampoline routing in any other way.
12:30 < t-bast> bitconner: and if you'd make that assumption, anyone can game your heuristic by using Acinq as a trampoline node
12:30 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #lightning-dev
12:30 < t-bast> BlueMatt: and that's what I've advocated to for more than a year on the PR!
12:31 < bitconner> t-bast: you still learn it's an acinq/phoenix wallet? that is more info than in source routing :)
12:31 < BlueMatt> t-bast: glad we're on the same page :)
12:31 < t-bast> bitconner: nooo you don't
12:31 -!- jonatack_ [~jon@37.170.82.107] has joined #lightning-dev
12:31 < t-bast> bitconner: because if you asusme that anyone can game your heuristic and will happily game it by routing breez or electrum payments through the acinq node
12:32 <@rusty> OK, hard time out from me.  Thanks everyone!
12:32 < bitconner> yes, so this gets back to my point from before: how much longer/bouncing between trampoline nodes is sufficient?
12:32 < BlueMatt> see ya rusty!
12:32 < bitconner> adios rusty!
12:32 < ariard> bye rusty!
12:32 < t-bast> See you rusty! I'll have to head out soon as well
12:32 < bitconner> not saying this needs to be answered right now, just pointing out this would be useful to quantify :)
12:33 <@rusty> t-bast:  please add a feature grab to the 829 PR title :)
12:33 < t-bast> bitconner: this will always be about the trade-off between cost efficiency and privacy, but trampoline lets you choose that trade-off for each payment you make
12:34 < t-bast> bitconner: I really think it allows each wallet or user to set the trade-off that's good for them, and that's something we need to offer different wallets with different trade-offs
12:34 < t-bast> rusty: will do!
12:34 < bitconner> also just trying to avoid labeling it as "no privacy downsides" when in practice i think there will be (because people aren't going wait for 1000 hop payments)
12:34 < t-bast> #action t-bast to grab a feature bit for trampoline in the PR title
12:34 -!- jonatack [~jon@37.173.106.99] has quit [Ping timeout: 260 seconds]
12:35 < t-bast> bitconner: but that's because you labeled it as "always a privacy downside" which is wrong
12:35 < t-bast> bitconner: I label it as "allows you to choose your privacy level"
12:35 < bitconner> t-bast: for paths of equal lengths i don't think that's refutable?
12:35 < cdecker> And it is a huge win for some users in terms of usability
12:36 <+roasbeef> bitconner: yeh the latency impact beyond 3 tramopoline nodes will really be pronounced imo, particularly as the sender gets no feedback w.r.t the progress of the route as well 
12:36 < bitconner> i recognize there is a point in which you can try to offset that tho
12:37 < t-bast> but why do you compare it to paths of equal length? that's not comparing apples to apples...and note that the existence of trampoline never prevents you from doing full source-routing either 
12:37 < ariard> roasbeef: unless you pick yourself as intermediary hop to confuse other trampoline nodes :) ?
12:37 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 240 seconds]
12:37 < BlueMatt> roasbeef: right interesting point IMO - if users have to trade off fewer hops cause trampoline is adding hops, you're likely better off doing source routing to get as much privacy as you can per-hop instead of letting trampoline do it.
12:37 < t-bast> roasbeef: that's not necessarily true, because failures between routing nodes will be reported and handled much faster than failures that have to go all the way back to a node on a mobile phone
12:38 < BlueMatt> t-bast: will mid-trampoline failures result in a trampoline hop retrying the trampoline forward?
12:38 < BlueMatt> that sounds....hard to do.
12:38 <+roasbeef> t-bast: but it telescopes/compounds, which is additive latency, failures may also need to go _all_ the way back as well 
12:38 <+roasbeef> so now you have retries both in the internal of the netwrk, and at the sender 
12:38 < t-bast> roasbeef: there's no way to actually measure that (unless with a somewhat complex simulator to compare the same payments with the same capacity conditions on each link) though
12:39 <+roasbeef> idk there's a pretty simple intuitive argument here imo: more hops is more latency, retries in the internal of the network is more latency, imagine the worst case failure condition where every node incrementally retries resulting in the sender retrying as well 
12:40 < bitconner> t-bast: why is it unfair to compare the information leakage of two equal length paths/
12:40 < bitconner> ?
12:40 < BlueMatt> in a privacy-ideal world, users would maximize the number of hops up to their latency tolerance, so I think thats at least somewhat fair
12:40 < t-bast> BlueMatt: it *may* result in that mechanism, yes
12:40 < t-bast> BlueMatt: depending on the error the trampoline node receives
12:41 < BlueMatt> though its definitely *easier* to implement trampoline in a "just pick three hops, its kinda private" way than implement a router that optimizes for at least 10 hops.
12:41 < t-bast> roasbeef: no because all hops are not equal
12:41 <+roasbeef> BlueMatt:  they don't control the overall number of hops in the true route though, right? as each trampoline node can potentially max out hops to get to the destination (tho cdecker says there're new limits now) 
12:41 < BlueMatt> and, notably, today's routing algorithms do not optimize for privacy.
12:41 < t-bast> roasbeef: hops between a mobile nodes are quite unequal to hops between server nodes
12:41 < BlueMatt> roasbeef: yes, I was speaking in a highly abstract sensen.
12:41 < bitconner> comparing equal length paths better highlights how much more information is leaked, from that it one can try to extrapolate how much randomization is need to recooperate the loss
12:42 < t-bast> bitconner: because trampoline will almost always result in longer flattened paths for the same payments (you pay more fees for the usability gains)
12:43 < t-bast> I gotta go guys, I'd really love to continue that discussion in a more structured way, it would be easier to progress and see which points are fully addressed or need more details
12:44 < t-bast> It would be great if you could list and summarize arguments against trampoline and maybe send that to me other email
12:44 <+roasbeef> re latencies, here's the forwarded HTLC resolution distribution of one of my nodes: https://imgur.com/a/LHAW1KA
12:44 < BlueMatt> yea, list or google hangouts would be nice for this
12:44 < t-bast> Then I can take all of these and start a document where I try to address them, so we don't keep on repeating the same things and can refer to what has already been sorted out
12:45 < cdecker> roasbeef: re nodes giving you the run-around chosing extermely long routes: they can already hold an HTLC for long time, which has the same effect...
12:45 < t-bast> I usually find the ML quite hard to follow once we start having a long thread, but if I get all your points I can put them on a github document where we can easily comment line by line of something like that
12:45 <+roasbeef> cdecker: but that can happen just due to "honest" behavior right? this isn't the maclicious case I'm talking about, the Q is on avg how many additional hops will reside between trampoline nodes in the actrual route? 
12:46 <+roasbeef> t-bast: lol yeh long threads are where ideas go to die....
12:46 < t-bast> roasbeef: xD
12:46 < BlueMatt> google hangout? but this time with bitconner not forgetting to upload the recording he made?
12:46 < t-bast> a github doc can be updated to remove obsolete points and narrow the discussion as we go, while keeping history available
12:47 < ariard> I think ml thread might be better thanks hangout if anyone wants to think hard about privacy/cost/latency trade-offs
12:47 < ariard> well a ml thread followed-up by a github doc
12:48 < t-bast> TBH I think a first step that would be more efficient would be start by sending me all your criticisms, then I can spend time to provide short/efficient answers to those, and we can iterate over it and if at some point it's not progressing, then we can unblock with a hangout meeting
12:48 < bitconner> t-bast: sounds good, we can try to pick it up on the ML. i think my comments are more regarding trampoline-style payments in general rather than the specific design, but hopefully it will lead to some fruitful resolutions in quantifying the tradeoffs :)
12:48 < bitconner> BlueMatt: oooof
12:49 < bitconner> dog at my laptop 🙈
12:49 -!- fiatjaf [~fiatjaf@2804:7f2:2a8c:f814:ea40:f2ff:fe85:d2dc] has joined #lightning-dev
12:49 < BlueMatt> F for the dog
12:49 <+roasbeef> F
12:49 < t-bast> Thanks guys! Great meeting again, thank you for your time!
12:50 < jkczyz> 🐶
12:50 < ariard> see you all!
12:50 < bitconner> one plus is that i can now track him with FindMyMac
12:50 < bitconner> thanks for chairing t-bast!
12:50 -!- t-bast [~t-bast@5.51.245.138] has quit [Quit: Leaving]
12:53 -!- joost [~joostjgr@81-207-149-246.fixed.kpn.net] has quit [Quit: Leaving]
13:57 -!- foxp2 [~foxp2@ec2-54-221-232-236.compute-1.amazonaws.com] has quit [Quit: \/\/]
14:03 -!- bmancini55 [8ff42f6a@143.244.47.106] has quit [Ping timeout: 240 seconds]
14:38 -!- foxp2 [~foxp2@ec2-3-94-65-1.compute-1.amazonaws.com] has joined #lightning-dev
14:46 -!- vtnerd [~vtnerd@50-82-248-114.client.mchsi.com] has quit [Ping timeout: 240 seconds]
15:00 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev
15:41 -!- fiatjaf [~fiatjaf@2804:7f2:2a8c:f814:ea40:f2ff:fe85:d2dc] has quit [Ping timeout: 272 seconds]
15:49 -!- foxp2 [~foxp2@ec2-3-94-65-1.compute-1.amazonaws.com] has quit [Ping timeout: 240 seconds]
15:49 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 240 seconds]
16:17 -!- ddustin_ [~ddustin@unaffiliated/ddustin] has joined #lightning-dev
16:18 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Read error: Connection reset by peer]
16:45 -!- laptop [~laptop@ppp-2-161.leed-a-1.dynamic.dsl.as9105.com] has quit [Ping timeout: 240 seconds]
16:47 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev
17:07 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #lightning-dev
17:13 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net]
17:17 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #lightning-dev
17:17 -!- riclas [~riclas@77.7.37.188.rev.vodafone.pt] has quit [Ping timeout: 260 seconds]
17:33 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 240 seconds]
17:50 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 264 seconds]
17:56 -!- musdom [~Thunderbi@202.184.0.102] has joined #lightning-dev
18:04 -!- rh0nj [~rh0nj@88.99.167.175] has quit [Ping timeout: 260 seconds]
18:06 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #lightning-dev
18:16 -!- rh0nj [~rh0nj@88.99.167.175] has joined #lightning-dev
18:19 -!- bitromortac_ [~admin@gateway/tor-sasl/bitromortac] has joined #lightning-dev
18:22 -!- bitromortac [~admin@gateway/tor-sasl/bitromortac] has quit [Ping timeout: 268 seconds]
18:29 -!- belcher [~belcher@unaffiliated/belcher] has quit [Read error: Connection reset by peer]
18:29 -!- belcher [~belcher@unaffiliated/belcher] has joined #lightning-dev
18:56 -!- jonatack_ [~jon@37.170.82.107] has quit [Read error: Connection reset by peer]
19:01 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has quit [Read error: Connection reset by peer]
19:05 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has joined #lightning-dev
20:03 -!- cryptosoap [~cryptosoa@gateway/tor-sasl/cryptosoap] has quit [Ping timeout: 268 seconds]
20:04 -!- bitromortac_ [~admin@gateway/tor-sasl/bitromortac] has quit [Ping timeout: 268 seconds]
20:04 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Ping timeout: 268 seconds]
20:04 -!- ghost43_ [~daer@gateway/tor-sasl/daer] has quit [Ping timeout: 268 seconds]
20:04 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Ping timeout: 268 seconds]
20:05 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 268 seconds]
20:09 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev
20:16 -!- cryptosoap [~cryptosoa@gateway/tor-sasl/cryptosoap] has joined #lightning-dev
20:16 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined #lightning-dev
20:16 -!- bitromortac [~admin@gateway/tor-sasl/bitromortac] has joined #lightning-dev
20:16 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #lightning-dev
20:20 -!- musdom [~Thunderbi@202.184.0.102] has quit [Ping timeout: 245 seconds]
20:21 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #lightning-dev
20:25 -!- harrigan- [~harrigan@ptr-93-89-242-202.ip.airwire.ie] has joined #lightning-dev
20:26 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has quit [Read error: Connection reset by peer]
20:28 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has joined #lightning-dev
20:30 -!- harrigan- [~harrigan@ptr-93-89-242-202.ip.airwire.ie] has quit [Ping timeout: 264 seconds]
20:31 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.]
20:45 -!- shesek [~shesek@unaffiliated/shesek] has quit [Remote host closed the connection]
20:46 -!- shesek [~shesek@164.90.217.137] has joined #lightning-dev
20:46 -!- shesek [~shesek@164.90.217.137] has quit [Changing host]
20:46 -!- shesek [~shesek@unaffiliated/shesek] has joined #lightning-dev
21:43 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 264 seconds]
21:48 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #lightning-dev
21:59 -!- musdom [~Thunderbi@202.184.0.102] has joined #lightning-dev
22:10 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Ping timeout: 268 seconds]
22:12 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #lightning-dev
22:20 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has quit [Ping timeout: 264 seconds]
22:35 -!- musdom [~Thunderbi@202.184.0.102] has quit [Ping timeout: 245 seconds]
22:42 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #lightning-dev
23:35 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 264 seconds]
--- Log closed Tue Mar 02 00:00:44 2021