00:10:01 <luigi1111w> <sech1> forcing all transactions to 16 outputs will slow down wallet scanning, what... 5-8 times? <= it will slow down daemon syncing by a lot as well
01:26:33 <nikg83[m]> 4/8/16 fake outputs when real outs are > 0/4/8 or something similar 
01:26:42 <nikg83[m]> s/fake/forced/
09:15:23 <atomfried[m]> regarding the timelocks, wasnt there a paper (PayMo) proposing payment channels? https://eprint.iacr.org/2020/1441.pdf wouldnt this require the timelock feature?
09:16:18 <atomfried[m]> or was there something wrong with what they proposed?
09:22:03 <Rucknium[m]> I have now made my submission to the Monero Vulnerability Response Process via HackerOne. The text itself is 11 pages (1.5 line spacing). With images, tables, and code appendices, it is 28 pages. 
09:34:22 <wfaressuissia> ""[12] https://eprint.iacr.org/2019/595.pdf", "https://eprint.iacr.org/2020/1441.pdf#page=5", "Comparison with [12].  ... An additional limitation of their proposal in terms of transaction privacy is that, since the timelock ... On the contrary, PayMo does not require any changes to the transaction scheme of Monero, nor it requires to add any functionality to the scripting language"
09:34:55 <wfaressuissia> "... wouldnt this require the timelock feature?" no , it wouldn't
09:38:40 <wfaressuissia> Treat that PayMo as interesting academic research that will not be deployed as is, since any changes in cryptography will make it likely incompatible. And there is demand for cryptography changes due to problems outside of payment channels which aren't priority now.
09:39:13 <atomfried[m]> ah ok i see
09:40:22 <wfaressuissia> Only people that develops fundamental cryptography scheme can decided what can be added on top. Everyone else has almost 0 influence on it since there are a lot of important dependencies that should be handled carefully in order to break security.
09:40:54 <wfaressuissia> * ... to not break security
13:29:47 <atomfried[m]> do we know if things like payment channels/networks could be possible with seraphis?
13:30:38 <sethsimmons> atomfried[m]: Their creation/development would be simplified IIUC, but I could be wrong. UkoeHB would be a better person to answer that :)
13:30:58 <sethsimmons> I believe output chaining and multi-sig are both easier, and both could be used to create payment channels depending on approach.
13:37:30 <UkoeHB> atomfried[m]: not that I know of (not that I have pondered it either), you could try asking the Firo guys if they have ideas
13:55:28 <atomfried[m]> maybe with scriptless scripts or something like that, but i need to understand the crypto which is used in monero a bit better first ...
13:55:59 <atomfried[m]> i just finished my masters degree, so i have some free time in the next month/months :D
14:09:19 <carrington[m]> Other than the Paymo paper (which seemed to come out of nowhere), I haven't seen any analysis of how payment channels could work on Monero or its future transaction models
14:14:03 <carrington[m]> Although according to this comment it was at least discussed in this channel to some degree
14:14:03 <carrington[m]> https://www.reddit.com/r/Monero/comments/jx6hhi/comment/gd1wiy1/
17:04:18 <Lyza> if payment channels are networked a la lightning network, might that not decrease privacy?
17:05:05 <Lyza> my understanding with lightning is that a well connected adversary can get a fair amount of metadata from LN itself, not just because of the L1 transparency
17:05:21 <Lyza> thinking about this blog post in particular: https://abytesjourney.com/lightning-privacy/
21:41:06 <carrington[m]> <Lyza> "thinking about this blog post in..." <- That was a great read. It has convinced me that Monero should do absolutely nothing about lightning until Bitcoin has spent a few more years fixing it
21:43:19 <Rucknium[m]> carrington: Probably cannot be fixed. And I am working on a research project in my head that shows that fees on Lightning Network will actually rise substantially, in long-term equilibrium, due to the opportunity cost of locking all that BTC liquidity in channels. The opportunity cost is not getting that sweet "DeFi" interest money from loaning out BTC.
21:44:22 <Rucknium[m]> Although someone here I think helpfully suggested that fees wouldn't risk to compensate for the opportunity cost, but, rather, Lightning Network user data would be sold 😳
21:44:45 <Rucknium[m]> * fees wouldn't rise to..
21:46:14 <carrington[m]> I've heard similar arguments that DeFi opportunity costs make Proof of Stake unsustainable
21:50:49 <Rucknium[m]> Interesting argument. I will add it to my research TODO list  🧐
21:51:37 <Rucknium[m]> I think that DeFi interest rates will fall, though, as the real risk of DeFi starts to become more apparent -- and as maybe the speculation that drives the borrower side becomes less profitable.
21:53:53 <Rucknium[m]> Wait, maybe I got my arguments mixed up. People pulling out of lending will make interest rates rise. But if DeFi actually does get safer, then interest rates should fall. 🤔
21:54:40 <Rucknium[m]> To me, DeFi in its current form seems kind of useless, in terms of actual social utility. I have not looked deeply into it though.
21:56:56 <UkoeHB> I am confused how you can have DeFi lending without all borrowers being overcollateralized, which seems like a big impediment to real volume.
22:01:08 <Rucknium[m]> UkoeHB: I mean, traditional group microcredit in developing countries requires no collateral, but I'm not sure how you would implement something like that in pseudonymous, permissionless DeFi. I'd bet someone is working on it as we speak.
22:01:51 <Rucknium[m]> Repeated games, maybe? There are a lot of ways to ensure cooperation. Economists have been writing papers on this for decades.
22:43:49 <atomfried[m]> <carrington[m]> "That was a great read. It has..." <- a lot of those things can be fixed i guess, the only (and to be honest huge) privacy concern is about the routing and the graph built by payment channels and the information which can be deducted by it.
22:43:49 <atomfried[m]> Maybe some ZK stuff can help here, such that no graph at all is known to the single nodes and only information like "yeah i can route to this node" instead of the whole graph can be used to route payment
22:48:17 <atomfried[m]> i am just writing this idea right out mind, and pply the property of being able to ask each node for the set of nodes it can route payments to without the number of hop information is enough to deduce the whole payment channel graph
22:48:47 <luigi1112> UkoeHB depends what "real volume" means :)
22:49:09 <luigi1112> there is certainly some level of demand for "portfolio loans" which is basically what defi lending is
22:49:14 <atomfried[m]> * right out from my mind, and