11:32:48 <aksion[m]> Hello! Why not include P2Pool mining in the official Montero wallet? Obviously, solo mining has outlived its usefulness for a long time. Replace the solo mining option in the official monero wallet with P2Pool mining.
11:32:48 <aksion[m]> And also make a commission for those who connect to a remote node, so that the holders of the full node recoup the costs
11:40:09 <hxr404> > <@aksion:matrix.org> Hello! Why not include P2Pool mining in the official Montero wallet? Obviously, solo mining has outlived its usefulness for a long time. Replace the solo mining option in the official monero wallet with P2Pool mining.... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/3410733055475897a455123bad4eae4d8a89db6b)
11:44:58 <aksion[m]> > <@hxr404:matrix.org> I don't think it would be good Idea to "replace" solo mining, solo mining is a vital part of how Monero works.... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/9ac8a9a2111028db9ec9d9845b1c881776594bad)
11:50:40 <hxr404> well the thing is, most people use XMRig for mining, I don't know anyone who mines using the wallet. But since the Wallet is the "official" reference implementation of Monero's mining, I'm not sure if it would be even possible to just "replace" it.
11:52:46 <hxr404>  * well the thing is, most people use XMRig for mining, I don't know anyone who mines using the wallet. But since the Wallet is the "official" reference implementation of Monero's mining, I'm not sure if it would be even possible to just "replace" it.
11:52:46 <hxr404> but maybe lets wait for some actual monero devs to come online (I'm just a random community member, so don't take me by word)
11:54:10 <hxr404> btw aksion are you talking about this: https://github.com/SChernykh/p2pool?
11:57:29 <aksion[m]> hxr404: Yes, this is understandable, I would like to see it in my wallet, especially since P2Pool mining still needs a full node. Then people would keep a full node in their wallet, which is positive for the Montero network.
12:11:38 <UkoeHB> What is Montero?
12:19:02 <aksion[m]> If you do not introduce p2pool mining into the official Monero wallet on a par with solo mining, then people will continue to mine on simple pools, killing the decentralization of the Monero network and enriching the owners of simple pools. The p2pool miner in the Monero wallet is the only way to motivate people to keep a full node on their computers. I support that p2pool mining in general should become the main one for Monroe.
12:19:36 <aksion[m]> s/Montero/Monero/
13:22:46 <gingeropolous> that would be cool aksion[m] . but i have a feeling folks will end up using remote nodes for p2pool. so, it will be better, sure, but ... we'll see
13:25:15 <aksion[m]> s/Monroe/Monero/
13:28:37 <aksion[m]> <gingeropolous> "that would be cool aksion..." <- Thanks! To strengthen the stability of the Monero network and eliminate the centralization of mining as a phenomenon, it is necessary to completely eliminate the possibility of mining in pools programmatically. The main way of mining for Monero is to make p2pool mining. Make a convenient p2pool mining miner on the official website of Monero
13:48:17 <aksion[m]> I have a suggestion on how to make Monero instantly the most popular in the World.
13:48:17 <aksion[m]> Let's give each person on Earth an equal number of coins (not anonymously), so that people can start mutual settlements. It won't make anyone richer or poorer. But there will be mutual settlements in Monero. Those who want anonymity - let them buy or mine for themselves additionally.
13:49:09 <Lyza> cool how do you verify identity to make sure each person only claims coins once
13:49:31 <chad[m]1> There's a troll among us 🤣
13:51:16 <aksion[m]> Lyza: On the retina of the eye, or biometrics (you can without a name)
13:52:22 <Lyza> oh cool and at the end we'll have a worldwide database of biometric markers *taps forehead*
13:53:32 <aksion[m]> Lyza: It's not a big deal. Honest people have nothing to fear, especially since only the rulers will have this base anyway. Let it be with us then
13:55:19 <moneromooo> This is a research channel. Try #monero please.
13:58:34 <aksion[m]> moneromooo: This is how a social study is proposed to increase the popularization of Monero. Just give it to everyone equally to start worldwide settlements
14:01:52 <moneromooo> Can an op get me ops please ? Someone not taking the hint.
14:31:57 <sethsimmons> <moneromooo> "Can an op get me ops please..." <- Cleaning this up on the Matrix side.
14:32:07 <sethsimmons> Last warning, aksion, more spam in off-topic rooms will not be tolerated.
14:38:03 <UkoeHB> reminder: meeting in ~2hrs (1700 UTC) https://github.com/monero-project/meta/issues/618
17:00:41 <UkoeHB> meeting time (https://github.com/monero-project/meta/issues/618)
17:00:43 <UkoeHB> 1. greetings
17:00:44 <UkoeHB> hello
17:00:57 <ArticMine> Hi
17:01:04 <rbrunner> Hello
17:01:10 <wfaressuissia> Hello
17:01:25 <Rucknium[m]> Reporting in.
17:01:42 <jberman[m]> Hello :)
17:03:50 <hxr404> hey there 👋
17:04:06 <UkoeHB> Today again will be ~open-ended. We can start with updates.
17:04:06 <UkoeHB> 2. what has everyone been working on lately?
17:05:39 <jberman[m]> Been working on the wallet-side binning implementation, should have a fairly fleshed out PoC ready for review today. I was writing up an overview of it yesterday and found a couple tweaks I want to make to make it stronger
17:06:29 <UkoeHB> me: I have continued to work on my Seraphis PoC. Today I was reminded how I suck at bit fiddling (this is broken https://github.com/UkoeHB/monero/blob/ace6c889a29838dde8494a82e21336bed6336314/src/mock_tx/mock_sp_core.cpp#L163).
17:07:12 <Rucknium[m]> (1) I have more or less finished writing out the mathematics of OSPEAD as a numerical optimization problem.
17:07:12 <Rucknium[m]> (2) Light recruiting efforts for MRL.
17:07:12 <Rucknium[m]> (3) An idea was floated to have a GUI interface for simulation of p2pool payouts. I may do it.
17:07:48 <Rucknium[m]> (4) Begun work on reproducing the Moser et al. (2018) analysis. jberman is helping with that.
17:10:10 <UkoeHB> Well I think we can move on. If anyone else has updates, feel free to drop them in as you want.
17:10:10 <UkoeHB> 3. discussion; any questions/comments/thoughts about anything on the agenda or the above updates or anything else? :)
17:11:06 <neptune> Re: transaction unlock_time, I have posted on-chain stats from the previous year (Oct 2020 - Oct 2021) to the GitHub issue: https://github.com/monero-project/research-lab/issues/78#issuecomment-941840213
17:11:11 <neptune> In the previous year, the timestamp lock was still not used, and block height locks only made up ~11% of usage otherwise. Most usage took place in unlock_time values < 15, which don't lock anything.
17:13:01 <UkoeHB> I want to bring up the multisig address generation refactor: https://github.com/monero-project/monero/pull/7877. This fixes serious problems with multisig address generation, but there doesn't seem to be anyone willing/able to review it... If things continue I may have to recommend disabling multisig completely until it is reviewed. Call to action: is there anyone out there who can dive in, learn how multisig works/is supposed to 
17:13:01 <UkoeHB> work, and review the PR?
17:13:34 <Rucknium[m]> neptune: Nice! Thank you. In #monero-space:monero.social there was some discussion about how a certain DNM likes time locks.
17:14:38 <rbrunner> "have to recommend disabling multisig completely until it is reviewed" Are the problems that bad with the current code?
17:14:43 <carrington[m]> rbrunner? They worked on multisig stuff in the past
17:14:44 <Rucknium[m]> UkoeHB: I suppose coinstudent2048[m] would be a good candidate.
17:15:20 <rbrunner> Yes! But only as a user. Did not have a clue when I tried to read up on the theory in UkoeHB's book :)
17:15:39 <Rucknium[m]> Maybe someone could set up a bounty for the PR review using http://bounties.monero.social/ ?
17:15:41 <UkoeHB> rbrunner: yes there is little or no protection against key cancellation or address hostage attacks during key gen
17:16:18 <neptune> Rucknium[m]: well, if they were referring to using unlock_time, they aren't currently using the timestamp mode.
17:17:01 <rbrunner> Yes, the idea of a bounty also crossed my mind. Maybe that would get the people who implemented the current full M/N multisig on board for a review
17:18:10 <rbrunner> Hmm, maybe has the problem to attract people that only pretend to review ... how would you notice that?
17:18:11 <carrington[m]> Seems difficult for some anon to prove they have reviewed a PR to the extent that they deserve a bounties payout
17:18:49 <Rucknium[m]> neptune: "We will probably soon limit XMR transactions to a certain max value because we are primarily a multisig market and as long as the monero developer don't come up with a decent multisig solution and locktime transaction support we wont favor XMR over BTC" <- That's what the DNM rep said
17:19:47 <Rucknium[m]> carrington[m]: I don't think we need an anon. Someone known to the community, but who might need a bit of an incentive to tackle the task.
17:19:52 <carrington[m]> The use of locktime in that instance is referring to the bitcoin type, I think
17:23:09 <neptune> My opinion otherwise from all the data (previous year and TheCharlatan's study) is that we would be safe to "remove support for" the timestamp locks (unlock_time > CRYPTONOTE_MAX_BLOCK_NUMBER) and for invalid values (unlock_time < block_height). I only see the block height lock as having any contention, since it is used, just rarely. We could just let it be still, and fix the others.
17:23:22 <ErCiccione> Haveno is willing to contribute to move things forward, but setting a bounty for a review doesn't sound optimal to me. Unless the reviewer is known
17:24:38 <rbrunner> That's a circle of maybe 5 people ...
17:24:57 <ErCiccione> Is the problem that we don't find reviewer because it's tricky to review the crypto? If that's the case maybe luigi1111 could take a look 
17:25:38 <ErCiccione> yeah but assuring that the reviewer has done a good job would be tricky if the person is unknown or unwilling to provide references.
17:26:32 <Rucknium[m]> Could we get isthmus 's company to review it? That may get expensive though. Or Cypher Stack?
17:28:13 <rbrunner> Expensive may still better than no multisig
17:28:24 <UkoeHB> imo the crypto isn't that crazy; most of it is algorithmic/protocol logic
17:28:25 <h4sh3d> UkoeHB: how long do you estimate the work for reviewing 7877?
17:28:40 <ErCiccione> This would be the first time that we don't have somebody able to review a pr in-house btw
17:28:41 <atomfried[m]> rucknium[m]: why not ask both?
17:28:58 <moneromooo> I'll review the code (as in, not the crypto). I was mostly afk today but I'll try to do it soon. luigi for the cypto would be ideal... stoffu also if you can interest them.
17:28:58 <ErCiccione> I'm not willing to work with cypherstack fyi
17:29:13 <UkoeHB> h4sh3d: maybe a week or two 
17:29:52 <UkoeHB> assuming you start out not know how it is supposed to work
17:29:59 <ErCiccione> sounds great thanks mooo
17:30:06 <Rucknium[m]> erciccione[m]: isthmus may be looking at a no-bid contract then ;)
17:33:35 <Rucknium[m]> UkoeHB: Is your Seraphis PoC CCS proposal ready to move to the "Funding required" stage?
17:34:01 <UkoeHB> Sure, it has been from the beginning
17:34:07 <h4sh3d> I take some time next week to do a review, but it's great if luigi can do it too
17:34:20 <UkoeHB> h4sh3d: great! thank you :)
17:35:46 * h4sh3d have to go sorry, cia
17:36:10 <rbrunner> Ah, regarding timelock: There was a post on Reddit, as decided here, to get feedback. IMHO nothing really surprising surfaced there.
17:36:12 <Rucknium[m]> A pointed question: Don't we have a fairly centralized personnel situation with both the CCS and GitHub maintainer being the same person? No offense at all intended to luigi, but it doesn't feel quite right.
17:36:35 <coinstudent2048[> I can't C++ and I don't know secure implementation practice. Sorry :(
17:37:18 <Rucknium[m]> The criteria for moving a CCS forward seems to be when luigi thinks that it is ready. Or maybe the criteria is written somewhere.
17:37:50 <fluffypony> that's pretty much how loose consensus works
17:37:53 <fluffypony> :-P
17:38:05 <fluffypony> https://en.wikipedia.org/wiki/Rough_consensus
17:38:19 <ErCiccione> Luigi considers feedback from the community, but at the end yes, it's at discretion of core
17:39:07 <carrington[m]> I think you are correct rucknium[m] about the centralization issue . It only became this way when snipa stopped being the lead maintainer
17:39:25 <ErCiccione> snipa was lead maintainer for a very short time
17:39:51 <UkoeHB> I think meta questions like that can be discussed in #monero-community. Does anyone else have research topics to discuss today? Otherwise we can end early.
17:41:30 <wfaressuissia> UkoeHB: can you mention explicitly minimum set of docs that describe math behind prev and new multisig ?
17:41:32 <UkoeHB> rbrunner: thank you for mentioning the reddit post; it seems there were a few ideas about use-cases (https://github.com/monero-project/research-lab/issues/78#issuecomment-935599960)
17:42:02 <wfaressuissia> prev (before your PR), new (after your PR)
17:43:48 <Rucknium[m]> UkoeHB: I have a topic: How do we fund researchers? I am making efforts to recruit, and things would be easier if the funding situation were clearer.
17:43:49 <UkoeHB> wfaressuissia: https://web.getmonero.org/resources/research-lab/pubs/MRL-0009.pdf and https://web.getmonero.org/library/Zero-to-Monero-2-0-0.pdf chapter 9; there are also a bunch of undocumented input-validation steps (i.e. there is nothing like an ietf protocol draft spec)
17:45:46 <UkoeHB> The existing code does not check that messages from other participants A) are from other participants (not rigorously anyway), B) contain the expected contents.
17:48:27 <UkoeHB> The main fundamental change between before/after is adding aggregation coefficients to the key-merge step (from the MRL paper). Other parts of the core algo are the same (aside from rigorous message validation).
17:53:47 <coinstudent2048[> Like does the existing code not check if EC points are not in the main subgroup?
17:54:55 <UkoeHB> No, it does not check that there is proper overlap between key shares recommended by different participants.
17:56:12 <UkoeHB> We are getting to the hour mark now. Should we meet again next week, same time? The discussion topics have slowed down the past couple meetings.
17:58:41 <coinstudent2048[> Hmm... I am not available this time period most of the time, but there seems to be questions and possible updates still, like rucknium[m]'s last, and (now) multisig review.
17:59:16 <UkoeHB> Ok fine with me. Let's meet again next week same time. Thank you for attending everyone.
18:00:27 <Rucknium[m]> I like having meetings every week for now. Maybe we don't have such a long list of topics as we have now gone through our backlog, but this meeting, for instance, revealed that there is a critical PR that isn't getting the attention it needs, and some efforts at resolving that issue.
18:01:58 <rbrunner> And if we pick up your question about financing researchers as a valid "research meeting topic" that will easily fill a full hour meeting I guess
18:02:54 <rbrunner> Even a "loose consensus" might be hard to achieve there :)
18:04:40 <Rucknium[m]> Maybe we don't quite need consensus. Maybe autonomous action would be sufficient ;)