--- Log opened Mon Dec 20 00:00:06 2021
00:25 -!- jb55 [~jb55@S010660e327dca171.vc.shawcable.net] has quit [Ping timeout: 268 seconds]
00:59 -!- riclas [riclas@77.7.37.188.rev.vodafone.pt] has joined #lightning-dev
02:04 -!- kexkey [~kexkey@static-198-54-132-153.cust.tzulo.com] has quit [Ping timeout: 256 seconds]
02:05 -!- kexkey [~kexkey@static-198-54-132-89.cust.tzulo.com] has joined #lightning-dev
02:32 -!- smach [~savio@177.12.49.3] has quit [Quit: Leaving]
05:27 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Quit: = ""]
07:04 < michaelfolkson> Transcript from the last spec meeting: https://github.com/michaelfolkson/bitcointranscripts/blob/lightning-2021-12-06/lightning-specification/2021-12-06-specification-call.md
07:04 < michaelfolkson> I think today's is going ahead just with reduced attendance https://github.com/lightning/bolts/issues/945
07:05 < michaelfolkson> In which case can you record again please vincenzopalazzo? :)
07:17 -!- evbo [~bosats@2601:47:4383:560:cd46:e119:54f6:fb49] has joined #lightning-dev
08:07 -!- smach [~savio@177.12.49.3] has joined #lightning-dev
08:43 -!- deanguss is now known as DeanGuss
09:04 -!- Gustavo[m] [~gustafmat@2001:470:69fc:105::aac] has joined #lightning-dev
09:42 -!- jb55 [~jb55@S010660e327dca171.vc.shawcable.net] has joined #lightning-dev
09:42 -!- jb55 [~jb55@S010660e327dca171.vc.shawcable.net] has quit [Changing host]
09:42 -!- jb55 [~jb55@user/jb55] has joined #lightning-dev
10:09 -!- joostjgr [~joostjgr@2a02-a450-1546-1-9bae-2d05-945-fca5.fixed6.kpn.net] has joined #lightning-dev
10:30 -!- xraid [~xraid@185.176.247.160] has joined #lightning-dev
10:49 -!- Guest49 [~Guest49@243.86.254.84.ftth.as8758.net] has joined #lightning-dev
10:53 -!- lndev-bot [~limnoria@165.22.79.207] has quit [Remote host closed the connection]
10:53 -!- lndev-bot [~limnoria@2a03:b0c0:3:d0::13b1:6001] has joined #lightning-dev
10:56 -!- t-bast [~t-bast@user/t-bast] has joined #lightning-dev
10:57 < t-bast> Good evening everyone!
10:58 -!- niftynei____ [~niftynei_@2600:1700:d0e:284f:db62:c328:aa5a:bfa0] has joined #lightning-dev
10:58 < t-bast> Are there people around for tonight's meeting?
10:58 < niftynei____> hey t-bast!
10:58 < t-bast> hey niftynei! I won't be alone here :)
10:59 < mschmoock> hi
10:59 < t-bast> hey mschmoock!
10:59 < mschmoock> :)
10:59 < niftynei____> no lonely xmas chats for #lightning-dev this year haha
10:59 < t-bast> ;)
11:00 < mschmoock> this is going to be a neat little session then
11:00 < t-bast> If we're a small crowd, I'm down for discussing dual funding / splicing / liquidity ads, it's next on my to-implement list once I'm done with anchor outputs for good
11:00 < cdecker[m]> Heya ^^
11:00 < mschmoock> ah
11:00 < t-bast> Hi cdecker!
11:00 < mschmoock> we have a bit of a clightning 'hangover'
11:00 < cdecker[m]> ^^
11:01 < mschmoock> pretty sure thats the wrong word
11:01 -!- smoked [~smoked@195.181.160.173.adsl.inet-telecom.org] has joined #lightning-dev
11:01 < t-bast> BTW, curious to know what your priorities are for c-lightning for the next 3 months?
11:01 < mschmoock> world domination I guess
11:01 < t-bast> Apart from finalizing offers
11:02 < mschmoock> today jb55 did a nice thing and send all public LN nodes 1 satoshi
11:02 < cdecker[m]> Good question, I guess stability and performance are the perennial topics
11:02 < t-bast> lol, with keysend?
11:03 < mschmoock> t-bast: jup
11:03 < cdecker[m]> I think Rusty is working on a surprise that I'm not allowed to reveal yet :-)
11:03 < mschmoock> he recorded the results here  https://jb55.com/s/3bbc82a53226630b.txt
11:03 < t-bast> well, that's interesting! When are going to know more about rusty's surprise?
11:03 < t-bast> Is it a xmas gift?
11:04 < cdecker[m]> It's up to him to reveal (I think it's still to be seen whether we'll get it into the next release)
11:04 < cdecker[m]> So it might be a late christmas present ^^
11:04 < t-bast> nice, that's going to be fun :)
11:04 < smoked> are we discussing https://github.com/lightning/bolts/issues/945 today?
11:05 -!- seardsalmon [~seardsalm@2600:100c:b0d0:70f7:c481:bb7:2f4e:a557] has joined #lightning-dev
11:05 < cdecker[m]> Lisa is working on streamlining liquidity ads, further decentralizing this kind of market
11:05 < cdecker[m]> smoked: we'll try ^^
11:05 < t-bast> smoked: depends on who joins, a lot of these topics need more implementations to show up than only c-lightning and eclair
11:06 < niftynei____> well, technically currently working on accounting, but should be done soon/before next release. after that i'm *hoping* to do splicing :D
11:06 < 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)
11:06 < niftynei____> i think our next release is going to be mostly a "features and improvements for clightning" release: accounting, Remote RPCs etc
11:07 < 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
11:07 -!- lucasdcf [~lucasdcf@177.197.65.214] has joined #lightning-dev
11:07 < 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
11:07 < 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)
11:07 < niftynei____> t-bast: that's dope! did you see that LNRouter shipped an interface for them?
11:08 < niftynei____> hoping he adds a marketplace overview page at some point haha
11:08 < 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 :)
11:08 < jb55> hi
11:08 < t-bast> where are you on anchor outputs by the way? Do you plan to enable it soon?
11:08  * t-bast waves at jb55
11:09 < t-bast> cdecker: what do you mean by RRPC exactly? Adding a secure channel to call RPC on a remote node?
11:09 < t-bast> cdecker: something similar to the PAKE thing roasbeef did recently?
11:10 < cdecker[m]> Nah, our RPC in a PC in reality, you can only talk to it via Unix sockets by default
11:10 < BlueMatt> mschmoock: lol I was wondering why I had gotten 1 sat lol
11:10 < t-bast> cdecker: ok, got it
11:10 < mschmoock> jep, me too until I found out jb55 talking about it in our irc chan
11:10 < 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
11:11 < niftynei____> t-bast: we're behind in terms of our utxo management strategy
11:11 < cdecker[m]> So people don't have to reinvent the wheel all the time
11:11 -!- ryanthegentry [~ryanthege@2600:1700:14d0:65e0:c85b:53ad:4aa6:bb91] has joined #lightning-dev
11:11 < t-bast> cdecker: that makes sense, and I can see how that takes time to integrate
11:12 < niftynei____> ohh wait a second t-bast. we support anchor outputs by default on v2/dual-funded opens. they're still experimental otherwise
11:12 < 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
11:12 < cdecker[m]> It's easier than I expected, since it's all separate processes initially with well-defined interfaces
11:12 < t-bast> niftynei: do you have automatic RBF though?
11:12 < t-bast> cdecker: but you need to write all the wrappers, right? So it's tedious work :)
11:13 < niftynei____> we only have auto RBF for certain onchain close stuff; you mean for channel opens?
11:13 < t-bast> niftynei: yeah I mean for htlc txs during force-close (and claiming anchors)
11:13 < 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
11:13 < niftynei____> htlc txs yes, but it's incredibly dumb and doesn't use 'external to the close' utxos
11:14 -!- joostjgr [~joostjgr@2a02-a450-1546-1-9bae-2d05-945-fca5.fixed6.kpn.net] has quit [Remote host closed the connection]
11:14 -!- joostjgr [~joostjgr@2a02-a450-1546-1-229a-2b5a-ac48-6d13.fixed6.kpn.net] has joined #lightning-dev
11:15 < 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
11:15 < niftynei____> we'll need 'external' utxos for anchors to move away from update_fee, go to zero_htlc etc
11:15 -!- guest5 [~guest5@2600:100c:b0d0:70f7:d84d:81b7:49ed:7141] has joined #lightning-dev
11:16 < BlueMatt> niftynei____: are y'all gonna do many-external-utxos, or just do a single in-c-ln-tracked utxo?
11:16 -!- seardsalmon [~seardsalm@2600:100c:b0d0:70f7:c481:bb7:2f4e:a557] has quit [Quit: Client closed]
11:16 < BlueMatt> I think we're leaning towards holding a single utxo for all channels
11:16 < BlueMatt> this assumes package relay, but, then, so does really anything "secure" in lightning
11:16 < 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
11:17 < 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)
11:17 < 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
11:18 < t-bast> BlueMatt: I'm down for finally merging the warnings PR!
11:18 < t-bast> cdecker: in the invoice it's not using TLV
11:18 < 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
11:18 < cdecker[m]> Yeah, warnings has been on the top of the list for way too long
11:18 < t-bast> cdecker: so readers shouldn't fail, they must ignore unknown fields
11:18 < cdecker[m]> Oh righto ^^
11:18 < 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
11:18 < t-bast> BlueMatt: do it!
11:20 < 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.
11:21 < cdecker[m]> Shall we start the meeting, or keep it an overall discussion?
11:21 < t-bast> BlueMatt: how do you plan to "lock" that utxo from the node operator (ie prevent them from spending it anyway)?
11:21 < cdecker[m]> We're missing an lnd representative if I'm not mistaken
11:22 < BlueMatt[m]> it seems so. hence the "just chat" meeting instead of "merge stuff", no?
11:22 < 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
11:22 < cdecker[m]> Sounds good to me ^^
11:22 -!- guest5 [~guest5@2600:100c:b0d0:70f7:d84d:81b7:49ed:7141] has quit [Ping timeout: 256 seconds]
11:22 < 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
11:23 < ryanthegentry> I'm here but dunno if I can fully stand in for LND 🤗
11:23 < BlueMatt[m]> nah, I dont think we need to do a formal meeting
11:23 < BlueMatt[m]> we can just chat :)
11:23 < cdecker[m]> Heya ryanthegentry :-)
11:23 < cdecker[m]> Ok, back to UTXO mgmt discussions then ^^
11:24 < t-bast> BlueMatt: but do you have a plan on how the upper layers would actually lock a utxo?
11:24 < 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
11:24 < cdecker[m]> I'd be interested in what others are doing too, we currently reserve for hours, but have a very simple coin selection
11:25 < 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"
11:25 < BlueMatt[m]> alternatively, we may just request it from the user when we need it
11:25 < 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.
11:25 < 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
11:26 < BlueMatt[m]> that's quite possible, yes, but we haven't settled on concrete api yet
11:26 < 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
11:26 < BlueMatt[m]> we've mostly only had discussions about whether we can get away with single-utxo vs multi-utxos (maybe per-channel)
11:26 < BlueMatt[m]> I know previously others had been discussing multi-utxo (likely one-per-channel), but I believe that is not required
11:27 < BlueMatt[m]> t-bast: fwiw there *is* a lock command in bitcoind rpc
11:27 < BlueMatt[m]> but it only applies to fundrawtransaction
11:27 < BlueMatt[m]> or "normal" coin selection
11:27 < t-bast> Yes but the node operator can unlock it...
11:27 < BlueMatt[m]> (IIRC, this may be out of date info)
11:27 -!- guest5 [~guest5@2600:100c:b0d0:70f7:61d6:d136:2e45:7b81] has joined #lightning-dev
11:27 < t-bast> We do use these locks
11:27 < cdecker[m]> Well, that'd be a rather byzantine operator ^^
11:27 < t-bast> But we have users who look at their utxos, think "well why is that locked" and unlock them from bitcoin-cli
11:27 < 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?
11:28 < t-bast> Yes, I think the only real option is to have users deposit that utxo indeed
11:28 < cdecker[m]> We don't make use of bitcoind's wallet at all, and have the onchain wallet integrated tightly
11:28 < 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
11:28 < 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" :)
11:29 < 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
11:29 < BlueMatt[m]> I mean you already manage spending commitment txn and whatever, what's one more utxo :p
11:29 -!- smoked [~smoked@195.181.160.173.adsl.inet-telecom.org] has quit [Ping timeout: 240 seconds]
11:30 < 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
11:30 < t-bast> Yeah exactly, but managing funding / fee-bumping / reorgs is painful, with all those rules...xD
11:30 < BlueMatt[m]> agree or disagree its a good writeup of some various ideas
11:30 < BlueMatt[m]> t-bast: I have't implemented it, but, honestly, I don't think that will be the case.
11:30 < cdecker[m]> Count me on the agree side of the discussion BlueMatt 
11:30 < t-bast> Thanks for the link, I'll read that
11:32 < t-bast> darosior also published something on the ML about strategies for choosing what feerate to use for time-sensitive transactions
11:32 < 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.
11:33 < darosior> Yeah but it was really specific to our needs and Lightning's ones are very differents
11:33 < BlueMatt[m]> t-bast: right, antoine's writeup there is more about how you manage utxos, but, yea.
11:33 -!- smoked [~smoked@195.181.160.173.adsl.inet-telecom.org] has joined #lightning-dev
11:33 < darosior> Oh it was only for feerates, sorry i'm only half lurking
11:33  * darosior out
11:34 < BlueMatt[m]> no, all good, both are relevant :)
11:34 < t-bast> Yes, these are good complementary "food for thoughts"
11:37 < niftynei____> there's definitely space in here for "lightning tx insurance policies" :P
11:38 < smoked> .0.0
11:38 < t-bast> wanna be an insurance company by yourself niftynei? I'll sign up for an insurance plan
11:38 < niftynei____> "pay me to guarantee that your channels always close before the deadline"
11:38 < t-bast> how do you provide guarantees?
11:39 < t-bast> can you make that verifiable or are you just assuming reputation for those insurers?
11:39 < niftynei____> 🤔
11:39 < 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.
11:39 < t-bast> Or are we pitching that to michael saylor so that his bitcoins are useful to someone? :)
11:40 < t-bast> BlueMatt: but the insurance company guarantees you that they'll pay up, how does that work for channel closing?
11:40 < BlueMatt[m]> that sounds good, have saylor just pay anytime lightning breaks and he can make you right
11:40 < BlueMatt[m]> he won't miss a few btc lol
11:40 < niftynei____> yeah, you'd just pay me some sats and if your channel force closes and you lose money, i owe you money
11:40 < t-bast> Insurance works because of legal contracts, not technical reasons, right?
11:40 < BlueMatt[m]> t-bast: that's just reputation 🤷‍♂️
11:40 < t-bast> ok, that's just reputation
11:40 < 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
11:40 < t-bast> I'd only sign up with michael saylor then
11:40 < niftynei____> this is very off topic haha
11:41  * BlueMatt[m] is over here leaving reactions on messages but only cdecker sees them.
11:41 < t-bast> it's an interesting topic though
11:42 < niftynei____> "anchor UTXO management too hard? pay watchtower59 for force close insruance instead!!"
11:42 < t-bast> reminded me as well of hedging high fees by being a miner
11:42 < 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
11:42  * cdecker[m] sees Matt Corallo 's reactions ^^
11:42 < niftynei____> t-bast: hahaha ooh that's good!
11:42 < 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
11:43 < 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
11:43 < cdecker[m]> That is.... if you can express the risk of a claim objectively it might work, but that's... hard :-)
11:44 < cdecker[m]> Sorry, still on insurances xD
11:44 < niftynei____> "buy BMNs to offset bitcoin tx fees"
11:44 < BlueMatt[m]> hashpower futures have been a discussion for....years
11:44 < t-bast> why lower denominations? just go big or go home xD
11:44 < niftynei____> cdecker[m]: yeah, you'd probably charge a % of the value of the channel that you're insuring?
11:45 < niftynei____> t-bast: to make it accessible to lower $$ bitcoin users! min investment is 200 euro rn iiuc
11:45 < BlueMatt[m]> I don't know if anyone ever actually managed to get liquidity on hashpower futures, but people keep talking about it.......
11:45 < cdecker[m]> And here comes FutureCoin xD
11:45 < 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 
11:46 < 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
11:46 < niftynei____> well, the BMN token buys you the output of some X amt of terahashes for 3 years
11:46 < t-bast> that's true, but mining centralization is yet another veeery wide topic
11:46 < joostjgr> hi guys, if anyone's getting too worried about new altcoins being invented here - how about the topic of sender authentication?
11:46 < BlueMatt[m]> darosior: yea, well fundamentally it requires trust that they can deliver, sooooooooooooo
11:46 < ryanthegentry> lol
11:47 < cdecker[m]> joostjgr: sure 👍
11:47 < joostjgr> i posted to the ml and made a spec pr - which should indeed probably be a blip
11:48 < 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
11:48 < joostjgr> yeah, besides form - what would be a good way to do it?
11:48 < t-bast> but a BLIP to standardize a few ways of doing sender auth with various trade-offs would make a ton of sense
11:48 < niftynei____> the MuSIg PR just got merged, does anyone know what this means for our PTLC roadmap?
11:49 < t-bast> niftynei: only got merged to secp256k1-zkp, not secp256k1
11:49 < 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.
11:49 < BlueMatt[m]> just redoing the gossip (if we do it right), is probably a six month affair
11:49 < 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
11:50 < BlueMatt[m]> if someone wants to sign up to do the awesome research project of working on privacy-preserving gossip, please do!
11:50 < BlueMatt[m]> (or if you know someone, I'm sure we can get a grant or whatever)
11:50 < t-bast> BlueMatt: that would be nice to have
11:51 < 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
11:51 < niftynei____> ah, didn't realize there's still a zkp -> libsecp step still for the MuSig2 stuff. 
11:51 < niftynei____> thanks for the link t-bast!
11:52 < joostjgr> t-bast: fair enough. i thought perhaps people have been thinking about this already in the past.
11:52 < 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 😭
11:53 < 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!
11:53 < niftynei____> is "privacy preserving gossip" the same as "removing UTXO outpoints from channel_anns"
11:54 < t-bast> it would be a good start :D
11:54 < niftynei____> hmmm yeah
11:55 < BlueMatt[m]> niftynei____: yea, that, basically. basically trying to build zk proofs of utxo ownership and put that in gossip
11:55 < 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
11:55 -!- BlueMatt [~BlueMatt@ircb.bluematt.me] has quit [Remote host closed the connection]
11:55 -!- BlueMatt [~BlueMatt@ircb.bluematt.me] has joined #lightning-dev
11:55 -!- jetpack [~jetpack@2605:2700:1:100e:ddb4:196e:c17a:3b92] has quit [Quit: ZNC 1.7.2+deb3 - https://znc.in]
11:56 < 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
11:56 < 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 :)
11:56 -!- ghost43_ [~ghost43@gateway/tor-sasl/ghost43] has joined #lightning-dev
11:56 < BlueMatt[m]> t-bast: note that *both* of those are in the channel_update, you don't need any kind of proof for that.
11:57 < BlueMatt[m]> though I know laolu doesn't feel super comfortable with that, but I very strongly disagree
11:57 < 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?
11:57 < BlueMatt[m]> the only reason to ever look at the utxo set during gossip is for anti-dos.
11:57 < t-bast> Yes, we do have all of these, and we expose a lot more than we probably don't really need to expose
11:57 < BlueMatt[m]> niftynei____: nope! who cares?
11:57 < BlueMatt[m]> niftynei____: there's already an htlc_maximum_msat field. we can just look at that.
11:57 < niftynei____> mmh yes,i see your point BlueMatt[m]
11:58 < 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?
11:58 < 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
11:58 < 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
11:59 < niftynei____> well lightning exists as a public service for permitting non-trusting parties to transact 
11:59 < 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.
11:59 < niftynei____> if you mix trusting parties into the mix, you lose repayment guarantees, no?
11:59 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Ping timeout: 276 seconds]
11:59 < 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.
11:59 < BlueMatt[m]> just one particular hop does
11:59 < niftynei____> but it does propagate to others in the case of channel failure
12:00 < 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
12:00 < BlueMatt[m]> niftynei____: well if you settle eod instead of having a channel balnce your channel will be *much* more reliable :p
12:00 < 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
12:00 < 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
12:00 < BlueMatt[m]> (mind you I dont believe anyone will actually do this, but its a thought experiement that highlights what you need from gossip)
12:00 < t-bast> I completely agree with you BlueMatt on not needing to know how two peers forward the payment between themselves
12:00 < BlueMatt[m]> t-bast: you can already lie today, though
12:00 < cdecker[m]> The tradeoff is much more about spammability vs. trusting not to spam
12:00 < BlueMatt[m]> just open a channel and then dont forward
12:01 < niftynei____> well sure, you don't care about the successful cases
12:01 < smoked> cdecker[m] can't they "pretend" already.  using a "wormhole attack" as a feature/service
12:01 < cdecker[m]> But it comes at a cost
12:01 < smoked> LNBIG that is
12:01 < niftynei____> it's the failures that are problematic
12:01 < BlueMatt[m]> smoked: no, because they're required to prove channel ownerships on-chain
12:01 < BlueMatt[m]> which is entirely useless!
12:01 < cdecker[m]> smoked: no, they can't pretend there's a channel, they can only skip after the fact
12:02 < smoked> sorry, I interpreted at the wrong phase
12:02 < 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
12:02 < 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.
12:02 < 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
12:02 < niftynei____> i think that my point is that the scope of the lightning protocol is how to negotiate and transmit value between untrusted parties
12:02 < 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.
12:02 < t-bast> true, we can definitely lie already today, and path-finding heuristics can take that into account, that's interesting
12:03 < 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
12:03 < smoked> the only other counter point cdecker[m] is that it violates the sender's hop-privacy assumptions/preferences
12:03 < niftynei____> you can introduce trusted nodes but that's not really within the purview of the lightning spec?
12:03 < BlueMatt[m]> niftynei____: no, you're missing my point entirely here, I think
12:03 < cdecker[m]> smoked: but that's not reintroduced by preventing them from making use of the info, that info is already leaked ^^
12:03 < niftynei____> "does the lightning network work with trusted parties?" yes, but who cares?
12:04 -!- jetpack [~jetpack@2605:2700:1:100e:ddb4:196e:c17a:3b92] has joined #lightning-dev
12:04 < 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
12:04 < 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
12:04 -!- geyaeb [~geyaeb@gateway/tor-sasl/geyaeb] has quit [Ping timeout: 276 seconds]
12:04 < niftynei____> earlier yes, i was missing your point but i'm on the page now BlueMatt[m] :P
12:04 < t-bast> you just need to build the secure channel between your two nodes and the custom protocol to enable that
12:05 < 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?
12:05 < BlueMatt> there's no reason anyone else in the network needs to know.
12:05 < BlueMatt> niftynei____: okay, cool
12:05 < cdecker[m]> Interesting t-bast, and it'd teleport right to the next hop / recipient, skipping all potential faults
12:06 < niftynei____> i mean, you care insofaras the payment arrives at its destination, and the receiver considers the payment settled
12:06 -!- geyaeb [~geyaeb@gateway/tor-sasl/geyaeb] has joined #lightning-dev
12:06 < joostjgr> you are guys aren't reinventing the legacy system that banks use to settle among each other right?
12:07 < BlueMatt> joostjgr: no, critically no one is suggesting implementing this
12:07 < BlueMatt> joostjgr: its just a thought experiment
12:07 < BlueMatt> about what the requirements are for gossip protocol
12:07 < cdecker[m]> Nah, don't worry, we're just talking about what is already possible today (until we get PTLCs)
12:07 < niftynei____> arrives at its destination: i need to know which paths can route my payment successfully
12:07 -!- rachelfish [~rachel@192.199.243.147] has quit [Ping timeout: 250 seconds]
12:07 < niftynei____> "route my payment successfully" -- contains enough capacity
12:08 -!- rachelfish [~rachel@192.199.243.147] has joined #lightning-dev
12:08 < niftynei____> as currently written, we have a pretty strict proof requirement for (potential) capacity -- onchain utxo
12:09 < 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
12:09 < niftynei____> if we relax this requirement, the tradeoff presumably is a reduction(?) in the reliability of transmission via a "payment channel"
12:09 < 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
12:09 < 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
12:10 < 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 
12:10 < cdecker[m]> Correct
12:10 < joostjgr> i liked rusty's idea of being able to use any utxo as anti-dos token for one or multiple (unrelated) channels
12:10 < cdecker[m]> Hm, I wonder how much we should care between router privacy and user privacy
12:10 < BlueMatt[m]> so, concretely, rusty's proposal was "proof of utxo ownership of value > X"
12:11 < BlueMatt[m]> there's no reason anyone else in the network needs to know.
12:11 < BlueMatt[m]> and that lets you announce channels up to X in aggregate capacity
12:11 < cdecker[m]> Less reliable payments -> more attempts -> more informed parties that there's something going on
12:11 < BlueMatt[m]> cdecker: yes, yes, yes, yes, yes we fucking need to care about on-chain privacy here
12:11 < BlueMatt[m]> holy fuck
12:11 < BlueMatt[m]> also what joostjgr said.
12:11 < cdecker[m]> Not saying we don't, but how do you weigh one's privacy versus the other?
12:11 < BlueMatt[m]> utxo ownership privacy is a huge issue for lightning today
12:12 < BlueMatt[m]> and being actively exploited at large scale
12:12 < BlueMatt[m]> cdecker[m]: I'm not really convinced there is a loss of precsion
12:12 < 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)
12:12 < BlueMatt[m]> you already today can go open a bunch of channels
12:12 < t-bast> it's just so easy to use your lightning activity to link your on-chain utxos, we really need to improve this
12:12 < BlueMatt[m]> and just not route payments
12:12 < BlueMatt[m]> I mean a ton of nodes do this dos basically on accident 😂
12:13 < smoked> is the  "proof of utxo ownership of value > X" anything other than a signed message associated with a UTXO?
12:13 < cdecker[m]> Yeah, not taking any position here, just pointing to potential tradeoffs ^^
12:13 < 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
12:13 < 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)
12:14 < BlueMatt[m]> smoked: you can likely do it in zero knowledge!
12:14 < cdecker[m]> smoked: presumably there are ZKP mechanisms that can decorrelate onchain footprint from proof
12:14 < 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
12:15 < 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)
12:15 < BlueMatt[m]> smoked: sure, but that's true of lightning's gossip announcements today, too.
12:15 < cdecker[m]> We need to revisit this once/if we start relaxing that ~=
12:15 < smoked> proof of ownership would require all other commitments to be excluded to be an ownership proof
12:15 < BlueMatt[m]> cdecker[m]: Laolu was on twitter, to some extent. but maybe I misunderstood him, best to check with him.
12:15 < BlueMatt[m]> smoked: I'm not sure I understand your issue here?
12:16 < cdecker[m]> Ok, need to check his twitter then ^^
12:16 < BlueMatt[m]> cdecker[m]: probably best to never, ever, ever do that :p
12:17 -!- guest5 [~guest5@2600:100c:b0d0:70f7:61d6:d136:2e45:7b81] has quit [Ping timeout: 256 seconds]
12:17 < cdecker[m]> Hehe true
12:17 < cdecker[m]> Anyway, gotta drop off ^^
12:17 < 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)
12:17 < BlueMatt[m]> see y'all.
12:18 < BlueMatt[m]> smoked: sure, you need double-spend protection.
12:18 < cdecker[m]> Thanks for the good discussion everyone, happy holidays, and relax a bit before the marathon restarts next year ^^
12:18 < t-bast> Thanks guys, it was fun!
12:19 < t-bast> Happy holidays, great time for quiet coding ;)
12:19 < cdecker[m]> Yeah, we should do general discussions every once in a while, I missed just discussing random stuff ^^
12:19 < BlueMatt[m]> t-bast: lol I do the same :p
12:20 < BlueMatt[m]> cdecker[m]: in-person meetups with everyone soon :p
12:22 -!- t-bast [~t-bast@user/t-bast] has quit [Quit: Leaving]
12:24 -!- niftynei____ [~niftynei_@2600:1700:d0e:284f:db62:c328:aa5a:bfa0] has quit [Remote host closed the connection]
12:24 -!- xraid [~xraid@185.176.247.160] has quit [Quit: Client closed]
12:24 -!- lucasdcf [~lucasdcf@177.197.65.214] has quit [Quit: Client closed]
12:29 -!- smoked [~smoked@195.181.160.173.adsl.inet-telecom.org] has left #lightning-dev []
12:44 -!- evbo [~bosats@2601:47:4383:560:cd46:e119:54f6:fb49] has quit [Quit: Leaving]
12:48 -!- dongcarl [~dongcarl@70.107.207.192] has joined #lightning-dev
13:06 < zkao> hey guys, the farcaster devs (farcaster is a fork of lnp-node adapted for doing atomic swaps) love the underlying tech stack behind lnp-node, in special the internet2 stack using zeromq sockets very smartly for all to all communication between microservices, with a peer connection for transmitting lightning peer messages. Because of that farcaster node is potentially interoperable
13:06 < zkao> with lightning nodes. Cheers
13:39 -!- Guest49 [~Guest49@243.86.254.84.ftth.as8758.net] has quit [Ping timeout: 256 seconds]
14:13 -!- rojiro [~rojiro@gateway/tor-sasl/rojiro] has joined #lightning-dev
14:21 -!- geyaeb [~geyaeb@gateway/tor-sasl/geyaeb] has quit [Remote host closed the connection]
14:22 -!- geyaeb [~geyaeb@gateway/tor-sasl/geyaeb] has joined #lightning-dev
14:41 -!- rusty [~rusty@tro1759202.lnk.telstra.net] has joined #lightning-dev
14:59 -!- rusty [~rusty@tro1759202.lnk.telstra.net] has quit [Ping timeout: 240 seconds]
15:33 -!- smach [~savio@177.12.49.3] has quit [Read error: Connection reset by peer]
15:36 -!- rusty [~rusty@203.221.41.134] has joined #lightning-dev
17:20 -!- bitromortac_ [~admin@gateway/tor-sasl/bitromortac] has joined #lightning-dev
17:24 -!- bitromortac [~admin@gateway/tor-sasl/bitromortac] has quit [Ping timeout: 276 seconds]
17:32 -!- riclas [riclas@77.7.37.188.rev.vodafone.pt] has quit [Ping timeout: 240 seconds]
18:06 -!- smach [~savio@177.12.49.3] has joined #lightning-dev
18:06 -!- smach [~savio@177.12.49.3] has quit [Remote host closed the connection]
18:07 -!- smach [~savio@177.12.49.3] has joined #lightning-dev
18:08 -!- smach [~savio@177.12.49.3] has quit [Client Quit]
18:51 -!- ghost43_ [~ghost43@gateway/tor-sasl/ghost43] has quit [Quit: Leaving]
20:52 -!- An0rak [An0rak@user/an0rak] has quit []
21:02 -!- An0rak [An0rak@user/an0rak] has joined #lightning-dev
21:21 -!- bitromortac_ [~admin@gateway/tor-sasl/bitromortac] has quit [Remote host closed the connection]
21:21 -!- bitromortac [~admin@gateway/tor-sasl/bitromortac] has joined #lightning-dev
21:35 -!- geyaeb [~geyaeb@gateway/tor-sasl/geyaeb] has quit [Remote host closed the connection]
22:29 -!- rusty [~rusty@203.221.41.134] has quit [Ping timeout: 256 seconds]
23:15 -!- An0rak [An0rak@user/an0rak] has quit []
--- Log closed Tue Dec 21 00:00:07 2021