Lightning Specification Meeting 2021/12/20

[t-bast]

The meeting will take place on Monday 2021/12/20 at 7pm UTC (5:30am Adelaide time) on Libera Chat IRC #lightning-dev. It is open to the public.

A video link is available for higher bandwidth communication: https://meet.jit.si/Lightning-Spec-Meeting

Pull Request Review

• Warning messages BOLT 1: introduce warning messages, reduce requirements to send (hard) errors #834
• Clarify commit broadcast Removed requirement to broadcast an outdated commitment transaction #942
• Anchor outputs clean-up anchors: follow up changes after initial zero fee anchors merge #903
• Add payment metadata to payment request Add payment metadata to payment request (feature 48) #912
• Clarify channel_reestablish requirements Clarify and relax requirements on channel_reestablish #932
• Route blinding Route Blinding (Feature 24/25) #765
• Onion messages BOLT 7: Onion message support (features 38/39) #759
• Add dust exposure threshold Add a max_dust_htlc_exposure_msat #919
• Simple turbo channels enablement Explicitly allow funding_locked early, and support alias scids (feat 46/47/50/51) #910
• Dynamic DNS support in gossip messages BOLT 7: add gossip address descriptor type DNS hostname #911 or BOLT 1: adds remote address to optional init_tlvs (IP discovery) #917

Long Term Updates

• Dual funding interactive-tx: Add dual-funding flow, using the interactive tx protocol (feature 28/29) #851
• Liquidity ads option_will_fund: liquidity ads #878
• Splicing Splice draft (feature 62/63) #863
• Offers Offers #798
• Simplified commitment Feature 106/107: option_simplified_update. #867
• Trampoline routing Trampoline Routing (2021 edition) (Feature 56/57) #829 and Trampoline onion format (Feature 56/57) #836
• Upfront payments / DoS protection Hold fees #843
• Peer storage backup Peer backup storage (feature 40/41/42/43) #881

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.

• lnprototest (https://github.com/rustyrussell/lnprototest)

[lightning-developer]

May I suggest to add #625 to the pull request review? While reviewing it I looked at the code of the common implementations and it seemed to me that the suggestion was never picked up. It seems to me that the PR may be closed and in the spirit of keeping this repo clean we might want to do that. Given my review it should be rather easy to discuss it and find consensus.

@t-bast wrote:

• Warning messages BOLT 1: introduce warning messages, reduce requirements to send (hard) errors #834

I would also like to note that this tiny PR at #942 seems relevant to #834

[TheBlueMatt]

Lets take Christmas week off :p.

[t-bast]

I'll be around, but if many people are off next week this will probably just be a casual chat and not a real spec meeting.

[t-bast]

May I suggest to add #625 to the pull request review?

IIRC this PR was dismissed, because going from MUST to SHOULD didn't met agreement.
We should let lightning labs decide if they want to close that PR or update it and move forward.

I would also like to note that this tiny PR at #942 seems relevant to #834

Thanks, added.

[joostjager]

Suggesting #946

[t-bast]

This meeting was replaced by a board discussion about various lightning topics, here are the IRC logs:

<smoked> are we discussing https://github.com/lightning/bolts/issues/945 today?
* seardsalmon (~seardsalm@2600:100c:b0d0:70f7:c481:bb7:2f4e:a557) has joined
<cdecker[m]> Lisa is working on streamlining liquidity ads, further decentralizing this kind of market
<cdecker[m]> smoked: we'll try ^^
<t-bast> smoked: depends on who joins, a lot of these topics need more implementations to show up than only c-lightning and eclair
<niftynei____> well, technically currently working on accounting, but should be done soon/before next release. after that i'm *hoping* to do splicing :D
<cdecker[m]> And I'm currently working on getting Rust into the c-lightning ecosystem, so we can build a Remote Remote Procedure Call interface (yes, RRPC xD)
<niftynei____> i think our next release is going to be mostly a "features and improvements for clightning" release: accounting, Remote RPCs etc
<cdecker[m]> Accounting: the way to show all the over-achievers in LN that they weren't making any money, due to all the rebalancings Xd
* lucasdcf (~lucasdcf@177.197.65.214) has joined
<t-bast> niftynei: great, it's going to be interesting to get liquidity ads shipped, I think we'll be able to experiment with it soon-ish in the Phoenix closed world
<niftynei____> splicing maybe/probably the release after? there's also a few things i'd like to add/change about how offers work (ways to send addresses, emails for goods delivery via the request invoice)
<niftynei____> t-bast: that's dope! did you see that LNRouter shipped an interface for them?
<niftynei____> hoping he adds a marketplace overview page at some point haha
<t-bast> niftynei: I saw that, but didn't look into it much yet, I really want to finalize a first version of anchor outputs RBF before I focus on the next big things :)
<jb55> hi
<t-bast> where are you on anchor outputs by the way? Do you plan to enable it soon?
* t-bast waves at jb55
<t-bast> cdecker: what do you mean by RRPC exactly? Adding a secure channel to call RPC on a remote node?
<t-bast> cdecker: something similar to the PAKE thing roasbeef did recently?
<cdecker[m]> Nah, our RPC in a PC in reality, you can only talk to it via Unix sockets by default
<BlueMatt> mschmoock: lol I was wondering why I had gotten 1 sat lol
<t-bast> cdecker: ok, got it
<mschmoock> jep, me too until I found out jb55 talking about it in our irc chan
<cdecker[m]> In order to be remotely reachable you had to use plugins that re-exposed it over a networked interface, so now we're collecting infos and will build a canonical one
<niftynei____> t-bast: we're behind in terms of our utxo management strategy
<cdecker[m]> So people don't have to reinvent the wheel all the time
* ryanthegentry (~ryanthege@2600:1700:14d0:65e0:c85b:53ad:4aa6:bb91) has joined
<t-bast> cdecker: that makes sense, and I can see how that takes time to integrate
<niftynei____> ohh wait a second t-bast. we support anchor outputs by default on v2/dual-funded opens. they're still experimental otherwise
<t-bast> niftynei: right, I remember rusty wanted to work on utxo management, but then offers and many other topics took a lot of time
<cdecker[m]> It's easier than I expected, since it's all separate processes initially with well-defined interfaces
<t-bast> niftynei: do you have automatic RBF though?
<t-bast> cdecker: but you need to write all the wrappers, right? So it's tedious work :)
<niftynei____> we only have auto RBF for certain onchain close stuff; you mean for channel opens?
<t-bast> niftynei: yeah I mean for htlc txs during force-close (and claiming anchors)
<cdecker[m]> Turns out we already have part of it in greenlight :-) And a new code generator script that should make these kinds of bindings easier in the future
<niftynei____> htlc txs yes, but it's incredibly dumb and doesn't use 'external to the close' utxos
* joostjgr has quit (Remote host closed the connection)
* joostjgr (~joostjgr@2a02-a450-1546-1-229a-2b5a-ac48-6d13.fixed6.kpn.net) has joined
<t-bast> Regarding spec topics, is there anything blocking https://github.com/lightning/bolts/pull/912 on the c-lightning side? Do you have opinions for or against? We've got a compat test between lnd and eclair, and I believe BlueMatt was interested in landing this as well
<niftynei____> we'll need 'external' utxos for anchors to move away from update_fee, go to zero_htlc etc
* guest5 (~guest5@2600:100c:b0d0:70f7:d84d:81b7:49ed:7141) has joined
<BlueMatt> niftynei____: are y'all gonna do many-external-utxos, or just do a single in-c-ln-tracked utxo?
* seardsalmon has quit (Quit: Client closed)
<BlueMatt> I think we're leaning towards holding a single utxo for all channels
<BlueMatt> this assumes package relay, but, then, so does really anything "secure" in lightning
<cdecker[m]> t-bast: I don't think so, we have all the context needed in the places we build the onion, just need to wire them in
<BlueMatt> t-bast: yea, I've been so behind on stuff. we shipped a release friday, so hopefully have a bit of time over the holidays to catch up. do plan on doing that and a few others (gonna go re-review the warnings pr and then just merge it, I think)
<cdecker[m]> Well, there's the rollout phase which may be painful: what happens if an unupdated sender get's an invoice with payment_metadata? I expect it to fail since the TLV type is 16
<t-bast> BlueMatt: I'm down for finally merging the warnings PR!
<t-bast> cdecker: in the invoice it's not using TLV
<BlueMatt[m]> t-bast: yea, I plan on reviewing it in the coming days, Unless there's some major thing I'm gonna hit merge when I do
<cdecker[m]> Yeah, warnings has been on the top of the list for way too long
<t-bast> cdecker: so readers shouldn't fail, they must ignore unknown fields
<cdecker[m]> Oh righto ^^
<niftynei____> BlueMatt: no idea what the utxo strategy is tbh, we haven't been discussing anchors internally; it's on the "coming soon" list still
<t-bast> BlueMatt: do it!
<BlueMatt[m]> niftynei____: yea, fair enough, same for us mostly. we're just not in a rush as long as package relay isn't done, but hopefully that finishes soon.
<cdecker[m]> Shall we start the meeting, or keep it an overall discussion?
<t-bast> BlueMatt: how do you plan to "lock" that utxo from the node operator (ie prevent them from spending it anyway)?
<cdecker[m]> We're missing an lnd representative if I'm not mistaken
<BlueMatt[m]> it seems so. hence the "just chat" meeting instead of "merge stuff", no?
<t-bast> I think we can loosely discuss spec topics without starting a formal meeting? I'll paste the logs from my IRC on github
<cdecker[m]> Sounds good to me ^^
* guest5 has quit (Ping timeout: 256 seconds)
<BlueMatt[m]> t-bast: I dunno, we kinda trust our users a bit more than most others, I think - our users are developers writing to our API, not "average joe's", that's one hop away :p
<ryanthegentry> I'm here but dunno if I can fully stand in for LND 🤗
<BlueMatt[m]> nah, I dont think we need to do a formal meeting
<BlueMatt[m]> we can just chat :)
<cdecker[m]> Heya ryanthegentry :-)
<cdecker[m]> Ok, back to UTXO mgmt discussions then ^^
<t-bast> BlueMatt: but do you have a plan on how the upper layers would actually lock a utxo?
<t-bast> BlueMatt: I  haven't done anything on eclair and kinda trust the node operator here, because unless I manage keys inside eclair that are external to bitcoind there's just no way to really lock it
<cdecker[m]> I'd be interested in what others are doing too, we currently reserve for hours, but have a very simple coin selection
<BlueMatt[m]> t-bast: what do you mean? We haven't settled on a particular API, no, but I assume because we're only going to rely on having one utxo, we may just tell the user "please send N BTC into a utxo with address Y"
<BlueMatt[m]> alternatively, we may just request it from the user when we need it
<BlueMatt[m]> quite likely the second, but again, we *really* just our users more than y'all can - our "users" are devs, the node operator is one further step removed.
<t-bast> BlueMatt: ok, so you would manage the private keys inside rust-lightning (or one of its upper layers) instead of leaving the private keys in bitcoind's wallet
<BlueMatt[m]> that's quite possible, yes, but we haven't settled on concrete api yet
<t-bast> My issue is that we let bitcoind manage the keys of everything that's not lightning, so we can't really lock these utxos, users could still spend them directly from bitcoin-cli
<BlueMatt[m]> we've mostly only had discussions about whether we can get away with single-utxo vs multi-utxos (maybe per-channel)
<BlueMatt[m]> I know previously others had been discussing multi-utxo (likely one-per-channel), but I believe that is not required
<BlueMatt[m]> t-bast: fwiw there *is* a lock command in bitcoind rpc
<BlueMatt[m]> but it only applies to fundrawtransaction
<BlueMatt[m]> or "normal" coin selection
<t-bast> Yes but the node operator can unlock it...
<BlueMatt[m]> (IIRC, this may be out of date info)
* guest5 (~guest5@2600:100c:b0d0:70f7:61d6:d136:2e45:7b81) has joined
<t-bast> We do use these locks
<cdecker[m]> Well, that'd be a rather byzantine operator ^^
<t-bast> But we have users who look at their utxos, think "well why is that locked" and unlock them from bitcoin-cli
<BlueMatt[m]> sure, right, I think I agree you may not want to trust the user to do that - can y'all eat the suck of making the user deposit a coin into a node-controlled utxo?
<t-bast> Yes, I think the only real option is to have users deposit that utxo indeed
<cdecker[m]> We don't make use of bitcoind's wallet at all, and have the onchain wallet integrated tightly
<cdecker[m]> Mainly to be able to swap out the backend, but the extra work turned out to be very helpful a couple of times
<BlueMatt[m]> right, I *think* LDK won't go that far and just force users to write code against an API that allows us access to a UTXO, its much easier when we aren't facing "human users" :)
<t-bast> We were very happy with not having to manage an on-chain wallet, but probably managing only a few utxos would make sense
<BlueMatt[m]> I mean you already manage spending commitment txn and whatever, what's one more utxo :p
* smoked has quit (Ping timeout: 240 seconds)
<BlueMatt[m]> also, may be relevant, ariard at some point wrote up some thoughts on how to (complexify) utxo stuff in anchor - https://github.com/lightningdevkit/rust-lightning/issues/989
<t-bast> Yeah exactly, but managing funding / fee-bumping / reorgs is painful, with all those rules...xD
<BlueMatt[m]> agree or disagree its a good writeup of some various ideas
<BlueMatt[m]> t-bast: I have't implemented it, but, honestly, I don't think that will be the case.
<cdecker[m]> Count me on the agree side of the discussion BlueMatt 
<t-bast> Thanks for the link, I'll read that
<t-bast> darosior also published something on the ML about strategies for choosing what feerate to use for time-sensitive transactions
<BlueMatt[m]> cdecker[m]: right, he has a few proposals. I think we can get away with less complexity, but it does depend a lot on exact nuance of the package relay we get.
<darosior> Yeah but it was really specific to our needs and Lightning's ones are very differents
<BlueMatt[m]> t-bast: right, antoine's writeup there is more about how you manage utxos, but, yea.
* smoked (~smoked@195.181.160.173.adsl.inet-telecom.org) has joined
<darosior> Oh it was only for feerates, sorry i'm only half lurking
* darosior out
<BlueMatt[m]> no, all good, both are relevant :)
<t-bast> Yes, these are good complementary "food for thoughts"
<niftynei____> there's definitely space in here for "lightning tx insurance policies" :P
<smoked> .0.0
<t-bast> wanna be an insurance company by yourself niftynei? I'll sign up for an insurance plan
<niftynei____> "pay me to guarantee that your channels always close before the deadline"
<t-bast> how do you provide guarantees?
<t-bast> can you make that verifiable or are you just assuming reputation for those insurers?
<niftynei____> 🤔
<BlueMatt[m]> t-bast: i mean that's the point of insurance...you don't guarantee something won't go wrong, you just pay to make it right if it does.
<t-bast> Or are we pitching that to michael saylor so that his bitcoins are useful to someone? :)
<t-bast> BlueMatt: but the insurance company guarantees you that they'll pay up, how does that work for channel closing?
<BlueMatt[m]> that sounds good, have saylor just pay anytime lightning breaks and he can make you right
<BlueMatt[m]> he won't miss a few btc lol
<niftynei____> yeah, you'd just pay me some sats and if your channel force closes and you lose money, i owe you money
<t-bast> Insurance works because of legal contracts, not technical reasons, right?
<BlueMatt[m]> t-bast: that's just reputation 🤷‍♂️
<t-bast> ok, that's just reputation
<niftynei____> nice thing about a onchain force close is that you can prove you lost money; the harder part is guaranteeing that the insurer pays you out
<t-bast> I'd only sign up with michael saylor then
<niftynei____> this is very off topic haha
* BlueMatt[m] is over here leaving reactions on messages but only cdecker sees them.
<t-bast> it's an interesting topic though
<niftynei____> "anchor UTXO management too hard? pay watchtower59 for force close insruance instead!!"
<t-bast> reminded me as well of hedging high fees by being a miner
<cdecker[m]> Yeah, I think insurance can't be done easily without trust. Fundamentally an insurance is an under-collateralized party, that works out because the chances of the collateral being needed is small
* cdecker[m] sees Matt Corallo 's reactions ^^
<niftynei____> t-bast: hahaha ooh that's good!
<t-bast> if you pay a lot of fees on your htlc txs, you can make up for it by being in a mining pool: you lose on one side of the bet, win on the other
<niftynei____> hmm yeah, really a nice market for the BMN token if we can ever get that purchaseable at lower denominations and in the USA lol
<cdecker[m]> That is.... if you can express the risk of a claim objectively it might work, but that's... hard :-)
<cdecker[m]> Sorry, still on insurances xD
<niftynei____> "buy BMNs to offset bitcoin tx fees"
<BlueMatt[m]> hashpower futures have been a discussion for....years
<t-bast> why lower denominations? just go big or go home xD
<niftynei____> cdecker[m]: yeah, you'd probably charge a % of the value of the channel that you're insuring?
<niftynei____> t-bast: to make it accessible to lower $$ bitcoin users! min investment is 200 euro rn iiuc
<BlueMatt[m]> I don't know if anyone ever actually managed to get liquidity on hashpower futures, but people keep talking about it.......
<cdecker[m]> And here comes FutureCoin xD
<t-bast> the issue is that futures protect you once, but if the feerate becomes high and just stays high forever, derivatives don't help you, you just have to always be on both sides of the bet 
<darosior> I think any argument of "mine yourself for hedging against X" degenerates into "have a contract with a couple of mining pool" which is lower cost but increases centralization by a lot
<t-bast> that's true, but mining centralization is yet another veeery wide topic
<niftynei____> well, the BMN token buys you the output of some X amt of terahashes for 3 years
<joostjgr> hi guys, if anyone's getting too worried about new altcoins being invented here - how about the topic of sender authentication?
<BlueMatt[m]> darosior: yea, well fundamentally it requires trust that they can deliver, sooooooooooooo
<ryanthegentry> lol
<cdecker[m]> joostjgr: sure 👍
<joostjgr> i posted to the ml and made a spec pr - which should indeed probably be a blip
<t-bast> joostjgr: hey! I answered on the PR, to be honest that's not a feature on my "requested" list and I believe there are many ways to do it depending on the trade-offs you'd like, so I don't think this is ready for the BOLTs
<joostjgr> yeah, besides form - what would be a good way to do it?
<t-bast> but a BLIP to standardize a few ways of doing sender auth with various trade-offs would make a ton of sense
<niftynei____> the MuSIg PR just got merged, does anyone know what this means for our PTLC roadmap?
<t-bast> niftynei: only got merged to secp256k1-zkp, not secp256k1
<BlueMatt[m]> niftynei____: honestly, I feel like we're almost jumping the gun even talking much about ptlc structure. I mean we should talk about it, but we have a few steps before we get there.
<BlueMatt[m]> just redoing the gossip (if we do it right), is probably a six month affair
<t-bast> niftynei: next step is standardizing Musig2 and getting it into libsecp256k1, then we can start having fun and doing all of the nice things described here: https://github.com/t-bast/lightning-docs/blob/master/taproot-updates.md
<BlueMatt[m]> if someone wants to sign up to do the awesome research project of working on privacy-preserving gossip, please do!
<BlueMatt[m]> (or if you know someone, I'm sure we can get a grant or whatever)
<t-bast> BlueMatt: that would be nice to have
<t-bast> joostjgr: to be honest I haven't thought about it enough to have good feedback on ways of doing sender auth, that would need some more brainpower
<niftynei____> ah, didn't realize there's still a zkp -> libsecp step still for the MuSig2 stuff. 
<niftynei____> thanks for the link t-bast!
<joostjgr> t-bast: fair enough. i thought perhaps people have been thinking about this already in the past.
<BlueMatt[m]> t-bast: yea, tbh I'm gonna be kinda pissed if we deploy a whole new gossip structure and *don't* get privacy preserving gossip in it, but at the same time I feel like none of us have the bandwidth to do all the legwork required to build it 😭
<t-bast> BlueMatt: very true, gossip always ends up at the bottom of the todo-list, because there's just so many other things and it kinda work today...but it really needs more love!
<niftynei____> is "privacy preserving gossip" the same as "removing UTXO outpoints from channel_anns"
<t-bast> it would be a good start :D
<niftynei____> hmmm yeah
<BlueMatt[m]> niftynei____: yea, that, basically. basically trying to build zk proofs of utxo ownership and put that in gossip
<BlueMatt[m]> t-bast: yea, but now we *have* to redo it to some extent, would be good to really do it right given we have to
* BlueMatt has quit (Remote host closed the connection)
* BlueMatt (~BlueMatt@ircb.bluematt.me) has joined
* jetpack has quit (Quit: ZNC 1.7.2+deb3 - https://znc.in)
<t-bast> I think the only information we need from gossip is "what's the maximum amount I can send between these two nodes and how much does it cost", you shouldn't really need to know more
<BlueMatt[m]> anyway, if anyone is available to work on such a project, (a) help me convince them to, and (b) if they need it, we can definitely get them grant money :)
* ghost43_ (~ghost43@gateway/tor-sasl/ghost43) has joined
<BlueMatt[m]> t-bast: note that *both* of those are in the channel_update, you don't need any kind of proof for that.
<BlueMatt[m]> though I know laolu doesn't feel super comfortable with that, but I very strongly disagree
<niftynei____> well it's also a bound on the amount of btc that either of those nodes are 'allowed' to send in payment traffic also, in some sense, right?
<BlueMatt[m]> the only reason to ever look at the utxo set during gossip is for anti-dos.
<t-bast> Yes, we do have all of these, and we expose a lot more than we probably don't really need to expose
<BlueMatt[m]> niftynei____: nope! who cares?
<BlueMatt[m]> niftynei____: there's already an htlc_maximum_msat field. we can just look at that.
<niftynei____> mmh yes,i see your point BlueMatt[m]
<BlueMatt[m]> niftynei____: in arguing with Laolu, I pointed out a thought experiment - if a two nodes want to relay a payment and don't have an on-chain channel at all, just settle end-of-day, why should any other node care?
<t-bast> But hiding too much will kill a lot of path-finding heuristics, and can hurt reliability, there will probably be a trade-off there
<BlueMatt[m]> if they relay a payment "correctly" and it gets to the destination, there's not really any reason for the sender or recipient to care in the slightest
<niftynei____> well lightning exists as a public service for permitting non-trusting parties to transact 
<BlueMatt[m]> t-bast: we already have htlc_maximum_msat, I believe electrum (and we, to some extent) already use that in place of utxo amount.
<niftynei____> if you mix trusting parties into the mix, you lose repayment guarantees, no?
* ghost43 has quit (Ping timeout: 276 seconds)
<BlueMatt[m]> niftynei____: sure, but if two nodes *do* trust each other, that trust doesn't propagate to others, the sender and recipient still don't have to trust each other.
<BlueMatt[m]> just one particular hop does
<niftynei____> but it does propagate to others in the case of channel failure
<t-bast> BlueMatt: true, but then it likely will be lying if you max_in_flight_amount is lower - sender cannot actually send htlcs of that size
<BlueMatt[m]> niftynei____: well if you settle eod instead of having a channel balnce your channel will be *much* more reliable :p
<cdecker[m]> I have to agree with Matt Corallo here, LNBig could have saved a lot if it were allowed to just pretend there are channels between their nodes
<joostjgr> i've worked quite a bit on pathfinding heuristics and my conclusion also always was that channels don't matter. just the max amount that can be relayed from peer a to b. but yes, anti-dos
<BlueMatt[m]> (mind you I dont believe anyone will actually do this, but its a thought experiement that highlights what you need from gossip)
<t-bast> I completely agree with you BlueMatt on not needing to know how two peers forward the payment between themselves
<BlueMatt[m]> t-bast: you can already lie today, though
<cdecker[m]> The tradeoff is much more about spammability vs. trusting not to spam
<BlueMatt[m]> just open a channel and then dont forward
<niftynei____> well sure, you don't care about the successful cases
<smoked> cdecker[m] can't they "pretend" already.  using a "wormhole attack" as a feature/service
<cdecker[m]> But it comes at a cost
<smoked> LNBIG that is
<niftynei____> it's the failures that are problematic
<BlueMatt[m]> smoked: no, because they're required to prove channel ownerships on-chain
<BlueMatt[m]> which is entirely useless!
<cdecker[m]> smoked: no, they can't pretend there's a channel, they can only skip after the fact
<smoked> sorry, I interpreted at the wrong phase
<niftynei____> i guess as long as you trust your channel party, the failure doesn't really matter does it lol. you just trust them to revert it to you at EOD etc
<BlueMatt[m]> niftynei____: I'm not sure I see your point - my point is that no one except the two parties in the channel that is being "not announced" need to care.
<cdecker[m]> Also, it's not an attack, a routing operator has found a cheaper and less faulty route, so they should be allowed to skip the inbetween nodes and get more fees
<niftynei____> i think that my point is that the scope of the lightning protocol is how to negotiate and transmit value between untrusted parties
<BlueMatt[m]> niftynei____: yea, how those two parties trust each other isn't the point - its whether that implicates anyone else outside of them that's my point here.
<t-bast> true, we can definitely lie already today, and path-finding heuristics can take that into account, that's interesting
<cdecker[m]> Doesn't change the outcome for the sender / recipient and encourages operators to run smaller nodes, rather than a single behemoth that fails easily
<smoked> the only other counter point cdecker[m] is that it violates the sender's hop-privacy assumptions/preferences
<niftynei____> you can introduce trusted nodes but that's not really within the purview of the lightning spec?
<BlueMatt[m]> niftynei____: no, you're missing my point entirely here, I think
<cdecker[m]> smoked: but that's not reintroduced by preventing them from making use of the info, that info is already leaked ^^
<niftynei____> "does the lightning network work with trusted parties?" yes, but who cares?
* jetpack (~jetpack@2605:2700:1:100e:ddb4:196e:c17a:3b92) has joined
<cdecker[m]> The important part is that nodes are free to introduce trust if they want to (trusted peers), but the protocol MUST work without them
<t-bast> interestingly that's something that is actually a real feature for trampoline: if you run two trampoline nodes T1 and T2, and T1 receives a request to forward to someone close to T2, T1 can just send all the payment details to T2 and let it forward in its place to save on fees
* geyaeb has quit (Ping timeout: 276 seconds)
<niftynei____> earlier yes, i was missing your point but i'm on the page now BlueMatt[m] :P
<t-bast> you just need to build the secure channel between your two nodes and the custom protocol to enable that
<BlueMatt> niftynei____: ignore those two nodes entirely and what they're doing under the hood. they can do what they want, indeed, its not inside the purview of the lightning spec. my point is only about the gossip network. if a sender wants to send through such a "fake" channel, why should the sender, or ultimate recipient, of the payment care?
<BlueMatt> there's no reason anyone else in the network needs to know.
<BlueMatt> niftynei____: okay, cool
<cdecker[m]> Interesting t-bast, and it'd teleport right to the next hop / recipient, skipping all potential faults
<niftynei____> i mean, you care insofaras the payment arrives at its destination, and the receiver considers the payment settled
* geyaeb (~geyaeb@gateway/tor-sasl/geyaeb) has joined
<joostjgr> you are guys aren't reinventing the legacy system that banks use to settle among each other right?
<BlueMatt> joostjgr: no, critically no one is suggesting implementing this
<BlueMatt> joostjgr: its just a thought experiment
<BlueMatt> about what the requirements are for gossip protocol
<cdecker[m]> Nah, don't worry, we're just talking about what is already possible today (until we get PTLCs)
<niftynei____> arrives at its destination: i need to know which paths can route my payment successfully
* rachelfish has quit (Ping timeout: 250 seconds)
<niftynei____> "route my payment successfully" -- contains enough capacity
* rachelfish (~rachel@192.199.243.147) has joined
<niftynei____> as currently written, we have a pretty strict proof requirement for (potential) capacity -- onchain utxo
<cdecker[m]> Yeah, that's the issue imho, if we allow anybody to announce anything they can basically arbitrarily reduce our ability to find a route. The fact that the route we chose (and got reinterpreted) contained cooperating / trusting nodes shouldn't be an issue
<niftynei____> if we relax this requirement, the tradeoff presumably is a reduction(?) in the reliability of transmission via a "payment channel"
<BlueMatt> cdecker[m]: right, but the point is mostly an anti-dos one - by rate-limiting the ability of potentially-malicious peers to announce bunk channels, we significantly hamstring attackers
<cdecker[m]> Yep, that's the fear. We need to find a good way to characterize the loss of precision vs. increase in privacy, which is hard
<t-bast> niftynei: I agree, this is likely going to be a trade-off between 1) payment reliability for senders and 2) privacy for routing nodes 
<cdecker[m]> Correct
<joostjgr> i liked rusty's idea of being able to use any utxo as anti-dos token for one or multiple (unrelated) channels
<cdecker[m]> Hm, I wonder how much we should care between router privacy and user privacy
<BlueMatt[m]> so, concretely, rusty's proposal was "proof of utxo ownership of value > X"
<BlueMatt[m]> there's no reason anyone else in the network needs to know.
<BlueMatt[m]> and that lets you announce channels up to X in aggregate capacity
<cdecker[m]> Less reliable payments -> more attempts -> more informed parties that there's something going on
<BlueMatt[m]> cdecker: yes, yes, yes, yes, yes we fucking need to care about on-chain privacy here
<BlueMatt[m]> holy fuck
<BlueMatt[m]> also what joostjgr said.
<cdecker[m]> Not saying we don't, but how do you weigh one's privacy versus the other?
<BlueMatt[m]> utxo ownership privacy is a huge issue for lightning today
<BlueMatt[m]> and being actively exploited at large scale
<BlueMatt[m]> cdecker[m]: I'm not really convinced there is a loss of precsion
<cdecker[m]> As long as each ZKP proof is >= than the sum of channels enabled by it we don't have an issue imho (current situation and with ZKP)
<BlueMatt[m]> you already today can go open a bunch of channels
<t-bast> it's just so easy to use your lightning activity to link your on-chain utxos, we really need to improve this
<BlueMatt[m]> and just not route payments
<BlueMatt[m]> I mean a ton of nodes do this dos basically on accident 😂
<smoked> is the  "proof of utxo ownership of value > X" anything other than a signed message associated with a UTXO?
<cdecker[m]> Yeah, not taking any position here, just pointing to potential tradeoffs ^^
<BlueMatt[m]> yes, indeed, there needs to be some confidence that someone saying they can route 10BTC in capacity can actually route that, obviously dont want someone with zero capital who pays zero fees to be able to claim that regularly :p
<t-bast> and this is a cool area of research, we really should get more people looking into this (instead of things like balance probing which don't work and never will)
<BlueMatt[m]> smoked: you can likely do it in zero knowledge!
<cdecker[m]> smoked: presumably there are ZKP mechanisms that can decorrelate onchain footprint from proof
<smoked> bc a signed message associated with a UTXO (ZKP or not) isn't proof of UTXO ownership (who wants to buy some UTXO attestations), it's just proof that the key to spend the UTXO is potentially lively
<cdecker[m]> Ok, I think nobody is objecting to the ZKP schemes, as long as the multiplier is small (UTXO amount proven ~= sum of channel capacity)
<BlueMatt[m]> smoked: sure, but that's true of lightning's gossip announcements today, too.
<cdecker[m]> We need to revisit this once/if we start relaxing that ~=
<smoked> proof of ownership would require all other commitments to be excluded to be an ownership proof
<BlueMatt[m]> cdecker[m]: Laolu was on twitter, to some extent. but maybe I misunderstood him, best to check with him.
<BlueMatt[m]> smoked: I'm not sure I understand your issue here?
<cdecker[m]> Ok, need to check his twitter then ^^
<BlueMatt[m]> cdecker[m]: probably best to never, ever, ever do that :p
* guest5 has quit (Ping timeout: 256 seconds)
<cdecker[m]> Hehe true
<cdecker[m]> Anyway, gotta drop off ^^
<smoked> requiring a UTXO sign a message isn't practically an anti-DoS measure because the marginal cost to issue another message is ~nil (because the commitment doesn't force other commitments to be forgone)
<BlueMatt[m]> see y'all.
<BlueMatt[m]> smoked: sure, you need double-spend protection.
<cdecker[m]> Thanks for the good discussion everyone, happy holidays, and relax a bit before the marathon restarts next year ^^
<t-bast> Thanks guys, it was fun!
<t-bast> Happy holidays, great time for quiet coding ;)
<cdecker[m]> Yeah, we should do general discussions every once in a while, I missed just discussing random stuff ^^
<BlueMatt[m]> t-bast: lol I do the same :p
<BlueMatt[m]> cdecker[m]: in-person meetups with everyone soon :p