03:44:38 <jtgrassie> MoneroKon 2022, exciting!
11:47:22 <iaccept> reddit is really slow going, would you be kind enough to upvote my topic? https://www.reddit.com/r/Monero/comments/qvv8ju/roast_my_monero_project/
12:31:04 <mj-xmr[m]> Shameless autopromotion:
12:31:04 <mj-xmr[m]> https://resilience365.com/interview-with-mj-xmr/
12:31:04 <mj-xmr[m]> Many thanks to john_r365 for his time and patience!
12:33:35 <mj-xmr[m]> ^ An article, that explains in layman's terms the somewhat cryptic monthly reports, that I publish.
12:35:14 <john_r365[m]> I’m a layman myself 😊 not a developer, so hopefully I conveyed things in terms that are widely understood
14:20:27 <sethsimmons> Just a heads up, taking another pass at Matrix<>IRC bridge issues today. Hoping this might be the resolution, but will update once it's done.
14:46:48 <john_r365[m]> Thanks Seth!
16:35:34 <sech1> Who K-lined all matrix users? And why, lol
16:36:02 <shillo> \o/
16:36:03 <jwinterm[m]> Every matrix account just got k-lined in -pools on libera 😬
16:37:26 <Epsilon> apparently it was accidental
16:43:44 <sethsimmons> Was it by someone?
16:44:00 <sethsimmons> If not, it could have been caused by the minor config change we just did to the IRC bridge for Matrix.
16:44:10 <sethsimmons> But Idk why it would do that.
16:47:59 <sethsimmons> <jwinterm[m]> "Every matrix account just got k..." <- AFAIK we didn't touch the bridge on -pools, so likely unrelated then.
17:02:22 <Epsilon> A Libera staff member accidentally K-Lined Matrix users by mistake afaik
17:03:48 <Inge> rip
17:04:07 <sethsimmons> Epsilon: oof
17:18:53 <aberdeenik[m]> https://cryptpad.sethforprivacy.com/pad/#/2/pad/view/mrIir3nL+ltHZhFXakxbldzLQB+MREb8tcd3W9quK7M/p/
17:18:53 <aberdeenik[m]> RFC for proposal for advocacy for  monero
17:18:53 <aberdeenik[m]> Send me an invite at https://cryptpad.sethforprivacy.com/profile/#/2/profile/view/iUxUDXYMsxLte5Jx3ZnOU9r95ufxlAri6ep2Fg93y6Q/
17:18:53 <aberdeenik[m]> Please send me request here and I will give you permission 
17:29:27 <atomfried[m]> maybe someone could contact the authors of this paper: https://eprint.iacr.org/2021/1445 maybe they are willing to research the ability to make bidirectional payment channels work for monero with seraphis
17:36:19 <sethsimmons> <atomfried[m]> "maybe someone could contact..." <- I'm already in contact, these are the same authors as PayMo
17:36:20 <sethsimmons> What is needed?
17:36:20 <atomfried[m]> oh nice to know that
17:36:56 <sethsimmons> I'm inviting them to MRL/MRLounge
17:38:46 <sethsimmons> Some more context from them:
17:38:46 <sethsimmons> > Wanted to bring to your attention, another work of mine that lets you do bi-directional payment channels in Monero! You don't need to change the transaction scheme. You need PayMo, my  previous unidirectional payment channel proposal and we show a technique that lets you do bi-directional payments. Key caveat is that you have to overcome the key-offset issue to let transactions be signed ahead of the spending key appearing on
17:38:46 <sethsimmons> chain. If the key offset is replaced with a different strategy, then we have a bi-directional payment channel for Monero. Check out https://eprint.iacr.org/2021/1445
17:40:56 <carrington[m]> Isn't presigning transactions solved by Seraphis.
17:40:57 <carrington[m]> ?
17:44:30 <atomfried[m]> yeah thats why i thought they should maybe have a look at seraphis in regards to their work, maybe a monero LN is right arround the corner and everybody is talking at cross purposes
17:45:13 <atomfried[m]> is this even an egnlish sentenc? talking at cross purposes...? idk but i hope you understand what i mean
17:45:19 <sethsimmons> The main author is @aravind2112 on Twitter, for those interested.
17:45:21 <atomfried[m]> s/sentenc/sentence/
17:45:31 <sethsimmons> I've already DM'd him to ask him to join #monero-research-lab:matrix.org and #monero-research-lounge:monero.social 
17:47:27 <carrington[m]> A bounty for a Monero payment channel PoC might be a good idea... 
17:47:27 <carrington[m]> Although I don't know the technical specs/requirements which would need to be in the bounty
17:49:28 <Rucknium[m]> The Lightning _Network_ is not a good model to follow. A<>B payment channels, i.e. not a network, could be a good innovation, though.
17:49:57 <atomfried[m]> why do you think LN is not a good model to follow?
17:50:44 <anarkiocrypto[m]> Payment channels could be useful for microtransactions and small purchases (e.g. coffee, public transit tickets, VPS payments).
17:50:55 <atomfried[m]> i know of different privacy concerns but my guess is that a lot of them could be solved 
17:51:12 <Rucknium[m]> It's a Rube Goldberg machine. Very complex. Not to mention that it tends toward centralization. Have you looked into its problems?
17:51:47 <atomfried[m]> yeah i have looked into some of its problems, but i am sure there are lots of problems i am not aware of
17:52:28 <atomfried[m]> for example the sleepy channels which are proposed claim to work without watchtowers, thats one complex problem solved already
17:52:54 <Rucknium[m]> Low fees on the LN is an NP-hard problem
17:52:54 <Rucknium[m]> https://www.mail-archive.com/lightning-dev⊙llo/msg02456.html
17:53:27 <atomfried[m]> thats not a problem since you do not need to actually find the optimal solution but just an "optimal enought" solution
17:54:13 <Rucknium[m]> In practice lots of LN transactions are failing now due to inability to find routes.
17:54:41 <Rucknium[m]> Seth For Privacy apparently lost BTC in his attempt to use the LN non-custodially
17:55:18 <atomfried[m]> solving dependenies in package management is also NP-Complete and every linux machine on earth still does provide a package manager
17:56:16 <atomfried[m]> actually i dont know if it is NP-Complete or NP-Hard, so lets say package management is NP-Hard
17:57:07 <Rucknium[m]> In practice, LN payments are failing. People are being pushed toward custodial LN solutions since doing in in a noncustodial way is too risky
17:57:33 <Rucknium[m]> See also Peter Rizun's work on LN problems: https://medium.com/@peter_r
18:00:14 <atomfried[m]> a lot of those problems are due to the fact that bitcoin transaction fees are high as fuck and moneros dynamic block size solves this
18:00:50 <atomfried[m]> i am using LN with all my friends, noncustodial and had a realy low failiure rate
18:01:10 <Rucknium[m]> https://threader.app/thread/1450156795889074179
18:01:10 <Rucknium[m]> "My experience with the Lightning network over the past few months has been awful."
18:01:11 <atomfried[m]> s/i am using LN with all my friends, noncustodial and had a realy low failiure rate/i am using LN with all my friends, noncustodial and have a realy low failiure rate(ofc thats not a good metric, I know)/
18:02:49 <atomfried[m]> yeah i read that:... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/91a4e07a508d520158aa3566835db0fe03483a15)
18:03:25 <atomfried[m]> aside from the channel thing and opening channels is maybe much more easy on monero because of the low fees(depending on the channel type=
18:03:27 <atomfried[m]> s/=/)/
18:03:40 <Rucknium[m]> atomfried: How long have they had to fix this? How many resources have the LN developers poured into it?
18:04:39 <atomfried[m]> do you realy not want to explore LN for monero because Seth For Privacy experience was that it does not work well with docker? (overexaggeration ofc)
18:04:51 <Rucknium[m]> Could Monero muster similar -- and even greater -- resources? Especially given that there are high priorities for Monero's core feature -- privacy -- that need attention?
18:06:12 <Rucknium[m]> People are free to develop a Monero LN. I'm not sure it's a good use of time.
18:06:37 <atomfried[m]> yeah but it seems that there are researchers out there in the wild already exploring payment channels for monero, so why my take is we should welcome them and see where all this is going
18:07:41 <Rucknium[m]> If they want to do it, that's fine. We should be pursuing other Layer 2 solutions as well and not pin our hopes on this particular one.
18:08:16 <sethsimmons> Direct payment channels is a great thing, a non-permissioned payment channel network (like LN) has too many issues, especially for the limited Dev/researcher resources for Monero.
18:09:04 <sethsimmons> But closed payment channel networks (like between you and your favorite merchants, friends, etc.) Could be a huge addition to the ecosystem and allows us to start moving more and more transactions off-chain that can easily be done off-chain.
18:09:34 <sethsimmons> Just important people realize payment channels != LN
18:09:45 <sethsimmons> There are other simpler approaches that can be taken with them.
18:10:10 <atomfried[m]> what about just allowing 2 hops in the network or something like that? has someone thought about this?
18:12:02 <Rucknium[m]> sethsimmons: That's what I'm saying. A<>B payment channels, or even very small networks would seem feasible. A massive network would lead to...massive challenges.
18:17:46 <sethsimmons> <Rucknium[m]> "That's what I'm saying. A<>B..." <- Agreed.
18:19:06 <sethsimmons> <atomfried[m]> "what about just allowing 2..." <- The thing is we don't need this in Monero -- we can move trusted p2p payments off-chain (A<>B direct payment channels) and untrusted p2p payments can remain on-chain. We don't have the arbitrary cap/fee market of Bitcoin, so we can take a more calm and specific approach to offloading some transactions.
18:19:48 <sethsimmons> If I need to pay someone one time or someone I don't trust at all, I just pay on-chain and pay a very minor fee. If it's someone I trust or pay frequently, I open a direct channel and use that instead to cut down on fees and unnecessary blockchain space usage.
18:55:46 <atomfried[m]> i understand that, but since every wallet has to scan the entire blockchain (from the creation date) i guess it is a good idea for monero to move as much tx offchain as possible because otherwise every user have to scan the transaction which harms the UX.
18:55:46 <atomfried[m]> Same is true for full nodes initial node syncing already takes up to days if not weeks. Imagine how long it will take in 30 years if the transaction volume keeps increasing and everything is written to the blockchain
18:56:07 <atomfried[m]> and i know ... moores law for cpus and memory is getting cheaper.
18:56:07 <atomfried[m]> But memory isnt getting any faster but i think it would nevertheless be a good idea to move some payments offchain
18:57:00 <atomfried[m]> ofc monero should always have the possibility to transaction onchain with low fees
18:58:47 <atomfried[m]> s/but/and/
19:00:31 <sethsimmons> > <@atomfried:matrix.org> i understand that, but since every wallet has to scan the entire blockchain (from the creation date) i guess it is a good idea for monero to move as much tx offchain as possible because otherwise every user have to scan the transaction which harms the UX.
19:00:31 <sethsimmons> > Same is true for full nodes initial node syncing already takes up to days if not weeks. Imagine how long it will take in 30 years if the transaction volume keeps increasing and everything is written to the blockchain
19:00:31 <sethsimmons> Monero nodes are quite quick to sync if you have an SSD, that's the only real bottleneck so far.
19:00:43 <sethsimmons> And RAM is getting significantly faster with DDR5.
19:00:55 <sethsimmons> And we're starting to see larger generational leaps in CPUs as well.
19:01:05 <entry1[m]> On chain secures the transaction though permanently without any room for error. Am I naive to think this? 
19:03:59 <sethsimmons> Yes, on-chain is always pref for security.
19:05:49 <atomfried[m]> has someone calculated how much faster memory and cpus need to get to keep up with a tx volume of X to be reasonable for wallet scanning and initial node sync?
19:05:49 <atomfried[m]> Or is this just some kind of feeling that this is on pair?
19:06:08 <sethsimmons> arcticmine has IIRC
19:08:02 <anarkiocrypto[m]> Keep in mind that many people who use and need Monero have older laptops or smartphones (~5-10 years old) and can't afford to buy the latest hardware or they have data caps/slow internet/need to use Tor.
19:08:23 <Rucknium[m]> atomfried: Myself, mj-xmr , and neptune are initiating a project to do some forecasting of tx volume and tx type to help inform the answer to this question.
19:09:36 <atomfried[m]> ok thats realy nice to see research being done (and already having been done) about this
19:12:53 <anarkiocrypto[m]> On-chain is secure, but off-chain could be a good option for small regular payments, e.g. daily public transit tickets, monthly VPS bills, morning coffee.
19:12:53 <anarkiocrypto[m]> Although this use case could be solved by selling optional monthly public transit tickets (i.e. 1 tx/month vs 30 txs/month), using an account balance for VPS bills (1 balance refill vs. small monthly txs) and coffee shop gift cards (1 gift card with enough balance for 1 week/month of coffees).
19:55:06 <carrington[m]> Yeah recurring payments are only needed if that's what is convenient/required in the context of a particular service. The more unique upside of payment channels IMO is "streaming money" for pay-as-you-go type services
20:39:24 <Rucknium[m]> I put together a rough draft of Monero's open research questions to help MRL prioritize work. Edits and feedback appreciated:
20:39:24 <Rucknium[m]> https://github.com/monero-project/research-lab/issues/94
21:35:37 <Torr> Is there any Monero component written in C?
21:43:18 <jwinterm[m]> Lmdb?
21:52:19 <selsta> lmdb is c, yes
23:50:35 <Torr> B tree based storage, eh.