Lightning Specification Meeting 2021/03/01

[t-bast]

The meeting will take place on Monday 2021/03/01 at 7pm UTC on IRC #lightning-dev. It is open to the public.

Pull Request Review

• Funding expiry Add funding expiry to channel open #839
• Distinct hrp for signet Bolt 11: add distinct HRP prefix for Bitcoin signet #844
• Closing fee requirement Update closing_signed fee requirement #847
• Clarify preimage reveal BOLT 5: fix up opposing MUST & MUST NOT statements. #848
• Clarify nonce size Clarify nonce size for onion cipher #849

Issues

Long Term Updates

• Discuss the possibility of a BIP-like structure for LN
• Trampoline routing Trampoline Routing (2021 edition) (Feature 56/57) #829 and Trampoline onion format (Feature 56/57) #836 (@t-bast)
• Offers Offers #798 (@rustyrussell)
• Upfront payments / DoS protection Hold fees #843
• Blinded paths Route Blinding (Feature 24/25) #765 (@t-bast)

Backlog

The following are topics that we should discuss at some point, so if we have time to discuss them great, otherwise they slip to the next meeting.

• Github built-in security tab for vulnerability disclosure (@ariard)
• Hornet (@cfromknecht)
• lnprototest https://github.com/rustyrussell/lnprototest (@rustyrussell)

---

Post-Meeting notes:

Action items

• @rustyrussell to ping aj about the bot when it's his daytime...
• Merge Add funding expiry to channel open #839
• Merge Bolt 11: add distinct HRP prefix for Bitcoin signet #844
• @t-bast to update Update closing_signed fee requirement #847 to relax only for anchor outputs
• Bikeshed BOLT 5: fix up opposing MUST & MUST NOT statements. #848 wording directly on the PR
• Merge Clarify nonce size for onion cipher #849

[joostjager]

What would you think of creating a much shorter agenda? Most of the times, there are many topics that aren't discussed because there is no more time. It could be beneficial to make a more conscious decision about this upfront. Or perhaps this is already embedded in a subtly changing order :)

[t-bast]

I think it's better if the agenda contains most of the topics that need discussion (which is more than we'll do in a single meeting).
We really don't need to follow the order I've currently set, that can freely change during the meeting.
Ideally we'd discuss that before the meeting, but in practice the coordination cost is too high...so I'd rather have a big-ish list in here, and we can let the chair (or the participants) choose the order in which we do things during the meeting?

That would work best with rotating chairs, to ensure this doesn't become biased by what I think should be on the agenda! If you want to chair tonight that would be great, feel free to not follow this agenda, and if there are points I'd really like to see covered I'll raise it during the meeting and we can let participants decide (if I'm the only one interested in a particular topic, it's a waste of time for the others to cover it and I'll wait for later). How does that sound?

[joostjager]

I am happy for you to be the chair. I understand the problem of coordination cost, either before or during the meeting. And also that you don't want to introduce bias, which is happening a little bit anyway because of the ordering. Text is linear. How about putting a 'last discussed' date behind the recurring items and by default starting with the one that hasn't been discussed for the longest time?

[t-bast]

Yes we can do definitely do that.

Again, the reason I think we should have more on the agenda than what we can cover is to allow us to follow a different order than what I've (arbitrarily) put here, depending on what people are interested in, so don't hesitate to push for specific items during the meeting. I really don't want my personal views to bias too much the topics that are discussed, don't hesitate to suggest topics or re-arrange the order.

It's a good idea to put a "last discussed date" on each, to be honest I don't know how to better handle items that have already been discussed, but have progressed a bit and are waiting for new inputs or previous reviewers to look again, without making us feel we're lingering on always the same small things and wasting time...maybe more aggressive tagging of specific people on PRs, but I've refrained from doing that because I don't want to be too invasive on people's review time...

[t-bast]

Meeting logs:

<rusty> #startmeeting
<rusty> ...
<rusty> :(
<cdecker> Yeah, sorry. Supybot is a bit quirky to setup :-(
<rusty> #action Rusty to ping aj about the bot when it's his daytime...
<rusty> OK, let's start minus bot.  Who is chairing?
<t-bast> I can chair if you want
<t-bast> The PR list I setup should be quite quick
<t-bast> I believe we should have time for the long term stuff and we'll poll the audience to choose which one(s)
<rusty> Ack #839, seems simple and good.
<t-bast> #topic https://github.com/lightningnetwork/lightning-rfc/pull/839
<t-bast> This PR simply sets the funding expiry explicitly to 2016 blocks
<cdecker> Nice and simple, I like it 👍
<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
<cdecker> I'll draft it up, and look into what the minimal set of information to keep around is
<t-bast> bitconner, what do you think of this simple suggestion from lnd's pov?
<niftynei> (+1 from me fwiw)
<bitconner> t-bast: lgtm, lnd will forget channels after 2016 blocks so this it is backwards compatible with our timeouts
<bitconner> (as the fundee)
<t-bast> great, you don't even have anything to implement then!
<bitconner> hehe ;)
<t-bast> except maybe a CPFP for the funder's point of view, but it can be manual for now
<t-bast> #action Merge #839
<t-bast> #topic Signest prefix for Bolt 11 invoices
<t-bast> #link https://github.com/lightningnetwork/lightning-rfc/pull/844
<rusty> bitconner: I like spec compliance before the spec is even written. Proves our God-like foresight powers...
<bitconner> i believe that is already possible via our cpfp engine, but it isn't done automaticaly
<bitconner> sometimes it's easier to write the code first, then write the spec xD
<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
<rusty> bitconner: no, I'm going with spooky foresight.  Damn your prosaic explanations!
<roasbeef> yep users can use cpfp to bump up funding in lnd, assuming they didn't use psbt to produce no change output 
<t-bast> :+1:
<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.
<rusty> But fundamentally they chose this confusion deliberately AFAICT?
<rusty> (Bitcoin addresses already have this issue, and they like it?)
<bitconner> rusty: 👻🔮
<t-bast> you mean between different signets or between signet and testnet?
<t-bast> looks like it's between testnet and signet from the bitcoin address' pov
<bitconner> probably depends on whether you're in the testnet-is-dead camp or not
<bitconner> i'd support having a distinct prefix for ln tho
<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" :)
<bitconner> lolol that's one way to remove all ambiguity, until signet-cash comes along :)
<cdecker> Then we just use the blockchain head, and your invoices are valid only 10 minutes in expectation xD
<t-bast> genesis-block re-use is going to become a thing
<cdecker> Anywho, do we care if signets clash?
<t-bast> I don't
<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
<cdecker> I'm a bit on the edge, going directly against core on this, but I think making unique prefixes would be nice
<bitconner> does anyone know the reason they went with the same prefix? maybe hw wallet support?
<bitconner> which would be a problem we are free of since i'm not aware of any hw lightning wallets atm
<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).
<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?
<rusty> But I'm happywith 'lntbs' ?  Anyone have any pref?
<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
<t-bast> 'lntbs' looks fine to me as well
<bitconner> tbs vs tb is a little close just on sight, but idk how many people are really visually inspecting prefixes
<bitconner> +1 for 'lntbs'
<rusty> lnsig seems like it's something else, so yes, +1 for lbntbs
<t-bast> did you really mean lbntbs or did you mean lntbs rusty?
<bitconner> prob typo?
* EndFiat has quit (Ping timeout: 264 seconds)
<t-bast> I guess so, let's go with that and merge the PR, sounds like we have an agreement
<rusty> Oops, yes!  Acked lntbs on the PR.
<t-bast> #action merge #844
<t-bast> #topic Closing fee requirement
<t-bast> #link https://github.com/lightningnetwork/lightning-rfc/pull/847
<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
<t-bast> This doesn't make sense anymore for anchor outputs, where we may keep the commit tx feerate artificially low
<t-bast> So this PR simply removes that requirement
<cdecker> Good find!
<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 ..."
<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).
<bitconner> makes sense to me, i think before we also used this as a heuristic to not accept crazy fee proposals tho
<darosior> cccccctbbtnrggnjtnfjrfbhdjbhlljvckdcfidnbhdi
<rusty> But we should explicitly say that it's not true for anchor featuress.
<rusty> Hello to darosior's cat.
<t-bast> hello to darosior's yubikey xD
<darosior> sorry about that, yubikey ^^
<bitconner> hello to darosior's cat's yubkey!
<darosior> x)
<t-bast> rusty: IIUC you'd like to keep the existing MUST, and only relax it for anchor outputs?
* EndFiat (EndFiat@gateway/vpn/mullvad/endfiat) has joined
<rusty> t-bast: yeah.
<bitconner> perhaps we want to recommend: "shouldn't be more than X*what-your-fee-estimator-says"
<bitconner> o/w it is very easy to just burn everything to fees if no check is performed
<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
<t-bast> So no need for a MUST from the start, right?
<rusty> t-bast: we want it to succeed, and prior to anchor outputs there was no reason to allow this.
<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?
<roasbeef> change here is to just use the same fee rate? 
<roasbeef> on the commitment, and disallow going lower? 
<bitconner> good point, yes that's true
<t-bast> Ok, I can change that to only relax for anchor outputs, that works for me as well
<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.
<bitconner> depending on how everyone's fee negotiation is implemented, you may not ever converge on an acceptable value however
<rusty> Say 253 sat/ksipa.
<bitconner> if both parties are being stubborn
<t-bast> alright I'll udpate the PR to only relax this for anchor outputs then, this way it's backwards-compatible
<cdecker> Only allowing for anchor outputs avoids nasty surprises when deploying as well
<t-bast> #action t-bast to update the PR to relax only for anchor outputs
<t-bast> #topic Wording clarification around preimage reveal attack
<t-bast> #link https://github.com/lightningnetwork/lightning-rfc/pull/848
<t-bast> This is a wording clarification, but this thing is subtle, it's really hard to get right IMO
<t-bast> bitconner: right, that depends on the algorithm right now, so better be safe and keep the non-anchor outputs unchanged
<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?
<t-bast> ACK, let's bikeshed on the PR?
<rusty> (I like all the suggestions, but they need to be merged into one change)
* EndFiat has quit (Ping timeout: 240 seconds)
<t-bast> Great, let's move on then
* musdom has quit (Ping timeout: 245 seconds)
<t-bast> #action bikeshed on the PR
<t-bast> #topic Clarify nonce size
<t-bast> #link https://github.com/lightningnetwork/lightning-rfc/pull/849
<t-bast> This one should be very simple
<t-bast> It just clarifies the nonce size we use
<cdecker> Yep, my bad for assuming it'd be 64bits everywhere, no objections to the change 👍
<rusty> Ack!  Yeah, the 96 came later (with the RFC standardization process IIRC).
<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
<roasbeef> yeh iirc there's a few diff RFCs that use diff sizes 
<bitconner> ack 👍
<cdecker> Nice, that was a quick one ^^
<t-bast> Great!
<t-bast> #action merge #849
<t-bast> What long term topic would you like to discuss now?
<rusty> Don't all speak at once!
<cdecker> Hm, undecided between trampoline and blinded paths :-)
<cdecker> Both are pretty late in their stage and would love to hear your experiences for trampolines for example (which ACINQ uses extensively iirc)
* t-bast hears a loud crowd yelling trampoline, is that only me?
<rusty> t-bast: not just you :)
<cdecker> Trampoline sounds interesting ^^
<t-bast> On the trampoline side, Electrum has made a lot of progress recently implementing it
<t-bast> They have the wallet code complete
<t-bast> And are working on the node-relay part
<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
<t-bast> I'm hoping we can get these locked in 2021 to allow wallet to interoperate in prod ;)
<rusty> t-bast: yes, what needs doing there exactly?  Having incompat deployments is a big fail 
<cdecker> I'm pretty sure we could implement the forwarding part purely as a plugin, would be like rusty's bounce but ad-hoc ^^
<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
<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)
<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.
<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 
* jonatack has quit (Ping timeout: 264 seconds)
<t-bast> It's mostly what's in this PR: https://github.com/lightningnetwork/lightning-rfc/pull/836
<roasbeef> are electrum clients actually routing nodes though also? 
<roasbeef> I was under the impression they already delegate forwarding/path finding in their current arch?
<t-bast> electrum wallet don't route AFAIK, but electrum desktop does IIRC
<t-bast> but I'm not 100% sure about the electrum desktop part
<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 ?
<roasbeef> there's a difference? 
<roasbeef> ah you mean electurm server vs electurm wallet? 
<t-bast> right, electrum server sorry
<t-bast> rusty: ACK
<cdecker> ack
<t-bast> roasbeef: but I'm not sure exactly how you configure it to enable lightning TBH
<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 
<roasbeef> iirc there's like 50 servers world wide or something like that 
<roasbeef> which doesn't include electrum x ? 
<roasbeef> if this is the case, then for them it really isn't much diff than just delegating path finding right? 
* EndFiat (EndFiat@gateway/vpn/mullvad/endfiat) has joined
<roasbeef> since the server knows the true destination 
<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
<t-bast> and in that case trampoline nodes can't unmask the sender/recipient
<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 
<t-bast> especially if the trampoline route can be electrum -> some eclair -> another electrum -> another eclair or something like that
<roasbeef> have y'all done tests in teh wild with multiple hops to get a better feel for the impact re latency/fees/tiemlock? 
<t-bast> roasbeef: what do you mean about the additional info?
<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 
<roasbeef> but that's a side point really, mainly that it won't neccersily mean better privacy 
<roasbeef> necessarily* can't type as usual 
<roasbeef> don't want to side track this tho as these points have been raised in teh past 
<ariard> hello
<t-bast> I'm not sure I understand why it necessarily means it's worse privacy either...
<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
<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) 
<cdecker> I think the current proposal disallows that
<roasbeef> t-bast: see this example, simple naive 2 trampoline node topology) 
<rusty> OK, feature bits added to titles.  Found a clash already, proposed a move ( joost's https://github.com/lightningnetwork/lightning-rfc/pull/814 )
<roasbeef> orly? interesting
<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
<cdecker> i.e., it mandates the recipient must be a trampoline iirc
<t-bast> roasbeef: yes, that has been disallowed for more than a year :D
<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 
<rusty> Yeah, we'll be trampolining by default I imagine.
<bitconner> given two paths of equal length, the one with trampoline hops has reduced privacy 
<t-bast> but there's more possible paths, not less
* jonatack (~jon@37.173.106.99) has joined
<t-bast> I think you're not up to date with trampoline TBH
<t-bast> so we're kinda talking past each other and don't really understand each other's points...
<t-bast> thanks rusty for udpating the PR titles
<bitconner> how can there be more possible paths if they're the same length?
<t-bast> but why same length? I don't understand what you mean
<cdecker> There can be potentially much longer paths: each trampoline hop can in theory be 20 hops itself to reach the next one
<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
<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
<cdecker> Practically a sender can only do X * network diameter on purpose though (where X is max number of trampoline hops)
<t-bast> bitconner: but then again, trampoline has never had that restriction, I don't know where you read that...
<bitconner> idt it's a restriction? i'm just saying if you compare those two paths qualitatively?
<t-bast> but you can't "compare these two paths", that doesn't make sense...
<bitconner> why not? the path the htlc takes over the network, i.e. the final path taken by the htlc
<ariard> t-bast: IIRC you have also a concern if you cumulate MPP and trampoline, i.e intersection of incoming paths
<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
<t-bast> ariard: that's true but that's unrelated to trampoline, that's true of MPP regardless of trampoline
<t-bast> ariard: and it only lets you know who is the previous trampoline node, not whether it's the payer or not
<t-bast> ariard: so on that front trampoline makes it better than non-trampoline
<bitconner> t-bast: that's a pretty strong assumption no?
<ariard> t-bast: trampoline make it worst as mpp will likely happen few hops after sender
<t-bast> bitconner: what is?
<ariard> or are you going to make it mandatory to only trampoline with a minimal distance
<bitconner> > "you'll have even more randomness in the trmapoline one because you'll likely take detours" 
<t-bast> ariard: that's what will happen *most of the time*, but privacy-conscious wallet can very easily defeat that heuristic
<bitconner> the shortest path may be directly through trampoline nodes
<ariard> t-bast: well I mean only trampoline with at least 3 hops of distance, that way you have a minimal anonymous set
<t-bast> bitconner: yes, but it will more often not be than with the current source-routed path-finding algorithms
<ariard> don't trampoline with your LSP
<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
<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
<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
<bitconner> imo it's difficult to conclude "there is no reduction in privacy" when there are cases where it does happen
<ariard> t-bast: yeah I just hope you will make it easy to opt-out for users who prefers to optimize for privacy
* BlueMatt still thinks this is a lot of effort to avoid 10ms and downloading 10MB of data
<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? 
<roasbeef> that's the way phoenix works rn iiuc 
<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
<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
<cdecker> Except it isn't 10ms on flaky mobile connections, and mobile is likely the largest number of dpeloyemnts we're going to see
<bitconner> i think it'd be difficult to quantify tho..
<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
<BlueMatt> cdecker: sorry, I meant 10ms as in the cost to run a route calculation
<roasbeef> t-bast: but it's additive tho right? those constriants, but now within a more restricted overlay topology 
<t-bast> bitconner: as long as we've allowed nodes to deploy it
<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.
<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...
<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
<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
<t-bast> The only thing you can hope to hide is who the payee is
<t-bast> And trampoline with more than 1 hop does exactly that
<roasbeef> there's leaking you're the payer, and leaking more information about the payee 
<rusty> I think it's better than the status quo, which is why I'm supportive.
* ddustin (~ddustin@unaffiliated/ddustin) has joined
<roasbeef> BlueMatt: if the previous hop is one of 5 trampoline nodes, is it really harder? 
* ddustin has quit (Remote host closed the connection)
<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
* ddustin (~ddustin@unaffiliated/ddustin) has joined
<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
<ariard> BlueMatt: I'm not sure if it holds with the decreasing order of cltv delays
<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
<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.
<BlueMatt> but maybe its harder.
* ThomasV (~ThomasV@unaffiliated/thomasv) has joined
<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
<roasbeef> yeh as ariard notes, there're other leaks like cltv delays, the "max" cltv limit, etc 
<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
<bitconner> BlueMatt: time locks?
<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
<BlueMatt> with no care for where they sit in the network.
* luke-jr has quit (Ping timeout: 276 seconds)
<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
<BlueMatt> bitconner: yes, thats a major issue. We need to randomize those.
<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"
<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 
<bitconner> where as with source routing breez only learns the outgoing node
<ariard> bitconner: add some block noise, don't consume rawly routing node policy, that's obsvervable by anyone
<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
<BlueMatt> t-bast: right, I think it would be wholly unreasonable to implement trampoline routing in any other way.
<t-bast> bitconner: and if you'd make that assumption, anyone can game your heuristic by using Acinq as a trampoline node
* luke-jr (~luke-jr@unaffiliated/luke-jr) has joined
<t-bast> BlueMatt: and that's what I've advocated to for more than a year on the PR!
<bitconner> t-bast: you still learn it's an acinq/phoenix wallet? that is more info than in source routing :)
<BlueMatt> t-bast: glad we're on the same page :)
<t-bast> bitconner: nooo you don't
* jonatack_ (~jon@37.170.82.107) has joined
<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
<rusty> OK, hard time out from me.  Thanks everyone!
<bitconner> yes, so this gets back to my point from before: how much longer/bouncing between trampoline nodes is sufficient?
<BlueMatt> see ya rusty!
<bitconner> adios rusty!
<ariard> bye rusty!
<t-bast> See you rusty! I'll have to head out soon as well
<bitconner> not saying this needs to be answered right now, just pointing out this would be useful to quantify :)
<rusty> t-bast:  please add a feature grab to the 829 PR title :)
<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
<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
<t-bast> rusty: will do!
<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)
<t-bast> #action t-bast to grab a feature bit for trampoline in the PR title
* jonatack has quit (Ping timeout: 260 seconds)
<t-bast> bitconner: but that's because you labeled it as "always a privacy downside" which is wrong
<t-bast> bitconner: I label it as "allows you to choose your privacy level"
<bitconner> t-bast: for paths of equal lengths i don't think that's refutable?
<cdecker> And it is a huge win for some users in terms of usability
<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 
<bitconner> i recognize there is a point in which you can try to offset that tho
<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 
<ariard> roasbeef: unless you pick yourself as intermediary hop to confuse other trampoline nodes :) ?
* rusty has quit (Ping timeout: 240 seconds)
<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.
<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
<BlueMatt> t-bast: will mid-trampoline failures result in a trampoline hop retrying the trampoline forward?
<BlueMatt> that sounds....hard to do.
<roasbeef> t-bast: but it telescopes/compounds, which is additive latency, failures may also need to go _all_ the way back as well 
<roasbeef> so now you have retries both in the internal of the netwrk, and at the sender 
<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
<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 
<bitconner> t-bast: why is it unfair to compare the information leakage of two equal length paths/
<bitconner> ?
<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
<t-bast> BlueMatt: it *may* result in that mechanism, yes
<t-bast> BlueMatt: depending on the error the trampoline node receives
<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.
<t-bast> roasbeef: no because all hops are not equal
<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) 
<BlueMatt> and, notably, today's routing algorithms do not optimize for privacy.
<t-bast> roasbeef: hops between a mobile nodes are quite unequal to hops between server nodes
<BlueMatt> roasbeef: yes, I was speaking in a highly abstract sensen.
<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
<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)
<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
<t-bast> It would be great if you could list and summarize arguments against trampoline and maybe send that to me other email
<roasbeef> re latencies, here's the forwarded HTLC resolution distribution of one of my nodes: https://imgur.com/a/LHAW1KA
<BlueMatt> yea, list or google hangouts would be nice for this
<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
<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...
<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
<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? 
<roasbeef> t-bast: lol yeh long threads are where ideas go to die....
<t-bast> roasbeef: xD
<BlueMatt> google hangout? but this time with bitconner not forgetting to upload the recording he made?
<t-bast> a github doc can be updated to remove obsolete points and narrow the discussion as we go, while keeping history available
<ariard> I think ml thread might be better thanks hangout if anyone wants to think hard about privacy/cost/latency trade-offs
<ariard> well a ml thread followed-up by a github doc
<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
<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 :)
<bitconner> BlueMatt: oooof
<bitconner> dog at my laptop 🙈
* fiatjaf (~fiatjaf@2804:7f2:2a8c:f814:ea40:f2ff:fe85:d2dc) has joined
<BlueMatt> F for the dog
<roasbeef> F
<t-bast> Thanks guys! Great meeting again, thank you for your time!
<jkczyz> 🐶
<ariard> see you all!
<bitconner> one plus is that i can now track him with FindMyMac

[t-bast]

@cfromknecht I was thinking about your comment yesterday:

<bitconner> given two paths of equal length, the one with trampoline hops has reduced privacy 

And I think it's just wrong, it may come from a misunderstanding of how trampoline works.
Can you detail why you'd claim that?

Let's suppose a "standard" path is:

+-------+        +-----+        +-------+        +------+
| Alice | -----> | Bob | -----> | Carol | -----> | Dave |
+-------+        +-----+        +-------+        +------+

A corresponding trampoline path could be (nodes on the bottom are trampoline hops, those above them are standard hops between trampolines - let me know if that notation is unclear):

                +-----+
    +---------->| Bob |------------+ +--------------+
    |           +-----+            | |              |
    |                              | |              |
+-------+                       +-------+        +------+
| Alice |                       | Carol |        | Dave |
+-------+                       +-------+        +------+

Same length, doesn't leak any more information.
Carol only learns that Bob is the previous node and Dave is the next one.
Bob doesn't even know trampoline is involved in the payment.
Dave doesn't even know Carol acted as a trampoline node: it could be another node before Carol in a standard route that was the previous trampoline.

Another corresponding trampoline path could be the following, where there is in fact only one standard hop between each trampoline node:

    +--------------+ +------------+   +-------------+
    |              | |            |   |             |
    |              | |            |   |             |
+-------+        +-----+        +-------+        +------+
| Alice |        | Bob |        | Carol |        | Dave |
+-------+        +-----+        +-------+        +------+

Same length, obviously doesn't leak any more information.
And on the contrary, it's pretty obvious that since flattened trampoline routes may be longer than standard routes, the anonymity set is bigger.

I suppose your misunderstanding comes from two wrong ideas about trampoline:

1. That flattened trampoline routes are constrained to 20 hops: this has never been the case
2. That the last trampoline node (the one before the recipient) gets full information about the recipient: this has never been the case either, this is why I've insisted that recipients support the trampoline onion format so that they can be just another trampoline node in the route

I admit though that point 2 means adoption will be slow, as we'll need recipients to support trampoline.
But there's no silver bullet, if you want something, you gotta work for it ¯|(ツ)/¯

[t-bast]

I think it would be really helpful to send me your criticisms of trampoline (no offense taken there, be harsh with it, it needs to take a few punches).

That would help me sort which ones are simply misunderstanding (we can clear these up once and for all and move on, and I'll maintain a FAQ document to refer to so that we don't block on the same points over and over) and which ones are things that need more work done.