00:47:31 <chaserene> Rucknium: I'd like to nominate two topics for tomorrow's meeting.
00:47:31 <chaserene> - I had a look at hyc's reorg data. as far as the data is representative, it gives cause for optimism with regard to reducing the lock time. https://github.com/monero-project/research-lab/issues/102#issuecomment-1577827259
00:47:31 <chaserene> - earlier this week here I/we wondered where exactly the bottlenecks are on the path to global membership proofs, and whether there is someone who is not yet involved in the effort but whose help could prove meaningful.
12:43:12 <xmrack[m]> kayabanerve: you were right it is RSA based. 
12:43:15 <xmrack[m]> https://moneroresearch.info/index.php?action=resource_RESOURCEVIEW_CORE&id=184&browserTabID=
12:43:59 * xmrack[m] uploaded an image: (30KiB) < https://libera.ems.host/_matrix/media/v3/download/matrix.org/YAOGYtFVNkkmoHfoYNnRIljM/ima_93e3f9d.jpeg >
12:44:54 <xmrack[m]> The search time tradeoff comes with a massive increase in address and key size, as expected
14:10:30 <Rucknium[m]> chaser: Thanks. They are on the agenda: https://github.com/monero-project/meta/issues/846
16:21:45 <UkoeHB> Meeting 40mins
17:00:05 <UkoeHB> Meeting time
17:00:11 <UkoeHB> 1. greetings
17:00:13 <UkoeHB> hello
17:00:17 <vtnerd> hi
17:00:18 <xmrack[m]> Hi
17:00:22 <rbrunner> Hello
17:00:24 <jeffro256[m]> Howdy
17:00:52 <chaserene> hello
17:01:08 <Rucknium[m]> Hi
17:03:12 <UkoeHB> 2. updates, what’s everyone working on?
17:04:02 <UkoeHB> Me: slowly putting together monerokon presentation. I’m considering taking a long break after monerokon to properly reset.
17:04:18 <Rucknium[m]> me: OSPEAD
17:05:23 <vtnerd> zeroconf webhoooks (LWS), otherwise and p2p-encryption / bp++. both are coming along slowly, but some progress is being made
17:05:28 <Rucknium[m]> There is a 90% probability that MAGIC will have something to announce about EAE attack research this week
17:05:31 <chaserene> I examined the long-term reorg data provided hyc
17:05:53 <jeffro256[m]> me: adding support for separation of coinbase/non-coinbase output distributions directly into BlockchainLMDB for issue #109
17:06:43 <jeffro256[m]> Rucknium[m]: Is it bad.... 
17:06:58 <Rucknium[m]> No
17:07:29 <Rucknium[m]> The announcement will be "please, community, fund this research so we know how bad it is"
17:07:37 <Rucknium[m]> And how it could be defended against.
17:08:33 <UkoeHB> 3. discussion
17:08:36 <chaserene> I truly wonder how it can be defended against other than churning
17:09:35 <chaserene> yeah, it's an art for now
17:10:34 <UkoeHB> chaserene: it sounded like you have some things you want to discuss today
17:11:04 <xmrack[m]> Increasing the ring size could help
17:11:04 <chaserene> yes. I wondered where the bottlenecks are exactly on the path to global membership proofs
17:11:04 <xmrack[m]> But it would need to probably be in the thousands of decoys
17:11:20 <chaserene> and whether involving new people and expertise could accelerate progress on it
17:12:22 <Rucknium[m]> Maybe ask Bailey if he wants to do this for trustless global membership proofs: Bailey & Miller (2023) "Formalizing Soundness Proofs of SNARKs" https://eprint.iacr.org/2023/656
17:12:39 <xmrack[m]> <xmrack[m]> "https://moneroresearch.info/..." <- UkoeHB: did you have a chance to read this paper/ have any thoughts on the concept?
17:12:42 <chaserene> Rucknium implied it's mostly a math problem for now, to which I answered that even hiring mathematicians and academics could be an option
17:12:54 <rbrunner> Maybe me manage to summon kayabaNerve, because he was so far a main force behind this push
17:13:03 <Rucknium[m]> That would also help us figure out what the state of the security proofs are in these papers
17:13:42 <Rucknium[m]> kayabanerve: What are the bottlenecks to implementing trustless global membership proofs in Monero?
17:15:24 <rbrunner> tevador has also been pretty active in the issue: https://github.com/monero-project/research-lab/issues/100
17:15:43 <chaserene> Rucknium[m]: thanks, that's a point to start at. there are all these researchers on whose efforts Monero is built, but I sense some kind of divide between their world and ours 
17:16:32 <Rucknium[m]> chaser: IMHO, if you want this to happen, you should contact Bailey
17:16:54 <rbrunner> Well, theory and implementing are by very nature quite different already, seems to me
17:17:02 <Rucknium[m]> I don't want to do it since I have a lot on my plate already. And cryptography isn't something I know
17:17:50 <UkoeHB> xmrack[m]: not yet
17:18:11 <Rucknium[m]> Sometimes there is a divide since what researchers come up with cannot be practically implemented in Monero (or any other usable system). I guess the idea is that research will eventually fix the problems that an unimplementable idea has.
17:18:44 <Rucknium[m]> For example, that paper that xmrack linked that wanted to have address sizes in the kilobytes
17:19:21 <Rucknium[m]> Or these papers that want a partitioning decoy selection algorithm. Those are a little closer to being practical, but with disadvantages.
17:19:25 <chaserene> Rucknium: I'm no cryptographer either. I'll take a look at the paper to have at least a basic understanding and see if I can formulate how Bailey can help in this
17:20:36 <plowsof11> i would just like to pop this invitation in from QuarksLab (if anyone was interested)- "We can schedule a new presentation of our activities and convictions in the next few days if that suits you, for example: June 8th between 14h and 16h / 13th afternoon /15th between 3pm and 5pm" if someone wants to "know how they could help the project", i am also going to poke the bp++ author again for an update on the final version of the pap
17:21:13 <Rucknium[m]> That's why MAGIC says that we would fund actionable research on Monero: https://monerofund.org/apply_research
17:21:23 <UkoeHB> plowsof11: that sounds valuable to me
17:21:24 <Rucknium[m]> (I wrote it)
17:21:40 <jeffro256[m]> Rucknium[m]: That's not necessarily completely infeasible, you already have to copy/paste XMR addresses, and a couple kilobytes can still fit on a QR code 
17:21:50 <Rucknium[m]> And it needs "A plan to work with Monero's developers and/or researchers to integrate the results of the research into Monero's protocol or ecosystem."
17:22:35 <rbrunner> Hardware wallets will surely thank us for 2KB addresses or so ...
17:22:50 <chaserene> Rucknium: yes, this is a much more promising avenue for this  than CCS
17:23:06 <chaserene> I dunno, I'm already freaked out by the Jamtis address lengths
17:23:52 <Rucknium[m]> plowsof: Are those UTC times?
17:24:18 <xmrack[m]> rbrunner: 2kb….. thats cute. They propose 37kb addresses 
17:24:28 <rbrunner> :)
17:24:33 <jeffro256[m]> oop
17:24:49 <plowsof11> I have no idea, i will get the times / tell them UkoeHB wants to attend (hopefully it is not just a sales rep reading a generic pdf) 
17:25:23 <Rucknium[m]> A presentation from them seems interesting to me
17:26:23 <plowsof11> great, ill pass this on and get times / more info 
17:27:39 <UkoeHB> Thanks plowsof11
17:28:16 <chaserene> while we're waiting for kayabanerve or tevador to pop in, I want to put this forward: visualization of hyc's long-term reorg data https://github.com/monero-project/research-lab/issues/102#issuecomment-1577827259
17:28:17 <chaserene> done by me, wholly non-quantitative, but has a few interesting insights
17:28:24 <jeffro256[m]> I wanted to bring this up so people can chew on it: is there any downsides to the #109 idea of when spending non-coinbase outputs, only selecting non-coinbase decoys? I have a couple in mind, but I don't want to bias ideas that people may have. 
17:28:31 <xmrack[m]> Nice work chaser 
17:29:20 <xmrack[m]> jeffro256[m]: Wouldnt an obvious downside be that when a coinbase output is spent it’s guaranteed to be the true spend? 
17:29:45 <Rucknium[m]> chaser: Thanks for the parsing of the log files. I think we could probably reduce the 10 block lock to 5 blocks. Probably. We would want to do more analysis and thinking about it.
17:30:31 <chaserene> namely,
17:30:31 <chaserene> * reorgs correlate w/ hash power
17:30:31 <chaserene> * reorgs relative to hashpower decreased a lot after Carbon Chameleon, and even more after Fluorine Fermi, and I wonder if you guys have a guess why
17:30:42 <Rucknium[m]> You could say if the real spend is a coinbase, then all ring members are coinbase outputs
17:31:12 <Rucknium[m]> chaser: I think sech1 helped improve network connectivity and reduced the probability of re-orgs
17:31:38 <jeffro256[m]> @xmrack Yes that's biggest one, when miners want to spend outputs it reveals their true spend. This isn't such a big issue for me though, since 1) 90% of miners are either p2pool or trad pool miners so miner spends are already public information or 2) if it's a solo pool miner, they can churn once to a normal output (wallet code would do this default ideally)
17:32:10 <chaserene> Rucknium[m]: a-ha
17:33:16 <jeffro256[m]> There was also the changes that ooo implemented which allowed for more p2p connections to stay alive and healty 
17:33:19 <chaserene> Rucknium: I would lean toward a more conservative reduction (8?), see how it performs in prod, and reassess whether to keep it, go higher or go lower. I agree with hyc's notion about unknown unknowns earlier in that thread. a reduction would invite more attackers who so far have been outpriced
17:33:48 <Rucknium[m]> chaser: I think this was the PR from sech1: https://github.com/monero-project/monero/pull/8675
17:34:19 <jeffro256[m]> ^^^^^
17:34:22 <chaserene> Rucknium: nice, thanks
17:35:06 <Rucknium[m]> If an attacker has enough hashpower to reorg 5 blocks, then Monero has bigger problems than the privacy issue with re-orgs
17:35:10 <Rucknium[m]> I agree that when the system changes, you could see the incentives change, so attackers could change behavior. But 5 blocks...?
17:35:26 <jeffro256[m]> https://github.com/monero-project/monero/pull/8426
17:35:59 <chaserene> jeffro256: thanks
17:36:17 <jeffro256[m]> Before PR #8426, a lot of connections were getting dropped and stagnating. Afterwards, alive connections went up on average by about 30% 
17:36:28 <xmrack[m]> jeffro256: what do you think of Rucknium idea to have coinbase outputs create rings using only other coinbase outputs. This way we stick to our ethos of private by default 
17:37:09 <Rucknium[m]> chaser: The 10 block lock can only be changed by a hard fork. Stepping it down gradually would take years
17:37:19 <UkoeHB> jeffro256[m]: from a meta point of view, a special rule for coinbase spends doesn’t solve the root problem which is inadequacy of ring signatures. Setting a precedent could have long term effects… which is an ambiguous complaint.
17:38:53 <jeffro256[m]> xmrack[m]: My PR actually does this currently, but it doesn't take into account amounts which reduces the effectiveness 
17:39:26 <chaserene> Rucknium[m]: yeah, I know. I can imagine attackers who aren't willing to attempt the whole thing with 10 blocks, but will come out of the shadows with 5. but of course I can't prove it would play out that way
17:39:52 <jeffro256[m]> UkoeHB: Yes, but this is a clear cut rule which raises the effective ring size for free in terms of on-chain data, and just a tiny overhead for RPC servers 
17:41:28 <jeffro256[m]> Obviously nothing is better theoretically than just increasing ring size, but look at the impact in practice, especially with p2pool
17:42:02 <Rucknium[m]> You could use the formula for 51% attack success probability to determine the hashpower for an occasionally successful 10 block reorg vs. 5 block reorg with minority hashpower
17:42:20 <UkoeHB> That path has a clear slippery slope. Say you make it a wallet rule, well now you have implementation variance. In response, we get pressure for a protocol rule. After that might come balance splitting (coinbase/non-coinbase), which is a wallet nightmare. What if some other use-case clearly divides the global money supply? The coinbase precedent will encourage going down the same route again.
17:42:26 <hyc> IMO the 10-block lock must stay unchanged. Tweak wallets to auto-create change like Monerujo did, if purchase convenience is an issue
17:44:13 <hyc> A more useful problem to tackle is speeding up IBD further. we've discussed methods a few times already but nothing's come of them.
17:45:00 <rbrunner> IBD = initial block distribution?
17:45:03 <hyc> allow nodes further than N blocks behind to use summary/checkpoint hashes, generated the same way as the hardcoded ones,
17:45:05 <hyc> yes
17:45:09 <chaserene> D = downuoad
17:45:18 <hyc> ^ yes
17:46:06 <UkoeHB> 10-block lock is a safety factor of at least 2.5, which is a good value. Idk if we can justify a lower safety factor.
17:46:29 <hyc> yeah, decreasing that is playing with fire
17:46:50 <Rucknium[m]> Here's that minority attack formula: https://www.worldscientific.com/doi/abs/10.1142/S021902491850053X
17:47:14 <jeffro256[m]> UkoeHB: I get the concern, but I don't think I buy this slippery slope argument since there is already a hard protocol difference between coinbase and non-coinbase outputs (coinbase outputs appear in special transactions in the block and have amounts encoded in tx prefix even when version > 1). 
17:47:41 <Rucknium[m]> Safety factor of 2.5? Is that in the github issue somewhere?
17:47:44 <chaserene> hyc: I agree speeding up IBD is good, but not sure how it's related to the problem caused by the 10-block lock
17:47:46 <rbrunner> Well, 5 blocks are still 10 minutes, which won't make all people happy anyway.
17:48:20 <hyc> chaserene: not related. IMO the 10-block issue needs to be dropped and forgotten.
17:48:38 <hyc> let the wallets deal with the UX.
17:49:03 <UkoeHB> Rucknium[m]: with a typical reorg depth of 2-3, we get a safety factor of at least 2.5
17:49:04 <chaserene> Rucknium[m]: I think he means that all the reorgs we see are 2-4 blocks deep
17:49:30 <rbrunner> With years between 4 block reorgs, right?
17:49:35 <hyc> decreasing the 10-block lock is foolish, if not totally reckless.
17:49:40 <Rucknium[m]> PocketChange and similar solutions probably reduce privacy. Consolidating pocketchange can improve guessing probability of real spends.
17:50:03 <chaserene> I don't know, those reaorgs don't have a clear date to them in the logs
17:50:25 <hyc> you will just have to estimate based on the logfile names
17:50:32 <hyc> and perhaps the line numbers in each logfile
17:51:26 <hyc> Rucknium[m]: I suppose this is the same problem we have from churning
17:52:03 <Rucknium[m]> Maybe some similarities with churning
17:52:34 <UkoeHB> jeffro256[m]: I’m not convinced, you can use any distinction to make an anonymity puddle. Whether the cause is a protocol rule or a user behavior, the result is the same in terms of privacy.
17:53:14 <Rucknium[m]> PocketChange consolidation is basically this problem: Borggren, N., & Yao, L. (2020). "Correlations of multi-input Monero transactions." https://moneroresearch.info/index.php?action=resource_RESOURCEVIEW_CORE&id=57
17:53:36 <hyc> yeah, understood
17:54:02 <Rucknium[m]> There is a warning in wallet2 when you spend two real spends that are close to each other in age...and both old, IIRC
17:55:11 <chaserene> <Rucknium[m]> "PocketChange and similar..." <- yes, I really didn't like how the Monerujo dev didn't mention at all the privacy tradeoff
17:55:31 <chaserene> in their announcements
17:55:44 <UkoeHB> We are approaching the end of the meeting, are there any last-minute questions or comments on other topics?
17:55:54 <Rucknium[m]> If coinbase outputs are not excluded from rings, then ring size should be increased to compensate for the number of black marbles that coinbases create
17:56:18 <Rucknium[m]> Maybe "proportion" is a better term than "number". Since coinbase outputs are included in proportion to their prevalence in recent blocks
17:57:09 <hyc> since we want to increase ringsize to N=128 or more anyway, just do that
17:57:51 <Rucknium[m]> The formula would be...something...to nominal ring size be equivalent to effective ring size at a particular (lower) ring size.
17:59:09 <Rucknium[m]> This issue with coionbase outputs was brought up months ago and there were no strong objections. I asked what the next step were...and nothing
17:59:09 <jeffro256[m]> Doesn't matter if ring size is 128, there's still X% of ring members which are coinbase when spending non-coinbase. Why not remove those ring members for free?
17:59:11 <Rucknium[m]> So there is a problem with the decisionmaking process here
17:59:32 <Rucknium[m]> jeffro's work is a sunk cost, of course. We don't have to do it just because the sunk cost was expended
18:00:16 <rbrunner> Removing is not "free", you rise the complexity of the system overall, and the codebase
18:00:46 <jeffro256[m]> <UkoeHB> "jeffro256: I’m not convinced..." <- You could say the same thing about pre-RCT decoy selection selecting outputs of the same amount. It creates puddles, but that's alright because the alternative is that cross contamination reduces effective rign size 
18:01:01 <rbrunner> The protocol becomes one wart more, to put it aggressively ...
18:01:09 <rbrunner> *gets
18:01:14 <Rucknium[m]> Of course, further research and analysis can uncover issues that were not considered before
18:01:50 <Rucknium[m]> This is an unavoidable curse of ring signatures. This overall problem was written when the Cryptonote paper was released
18:02:18 <Rucknium[m]> Everyone has accepted this problem 
18:02:57 <rbrunner> Maybe "everyone" is a bit much :)
18:03:05 <Rucknium[m]> There are some protocols that ignore these ring signature problems, e.g. Zano and Mobilecoin. I hope Monero does not become one of them
18:04:00 <Rucknium[m]> What I mean is Monero was born with this problem. By trying to improve Monero, you accept that the system is imperfect
18:04:18 <rbrunner> Ah, ok, I see
18:04:46 <UkoeHB> jeffro256[m]: overall I’m not against it being a wallet feature, but we should keep in mind the trade offs and dangers
18:05:11 <UkoeHB> We are past the hour so I’ll call it here, thanks for attending everyone
18:06:15 <jeffro256[m]> Agreed, thanks for letting me bounce ideas off you 
18:07:49 <hyc> just a note on reducing the 10-block lock - you should expect to see a nonlinear, hysteresis effect. not many multi-block reorgs because everyone knows attacking the 10-blocks is too hard.
18:08:31 <hyc> but as that number comes down, the feasibility of attack will make reorg frequencies increase beyond the rates we see now
18:09:26 <jeffro256[m]> That's a good point that I didn't think about
18:10:41 <chaserene> hyc: yes, I agree that this is what would happen. the unknown that is the hash power at the sidelines
18:12:04 <chaserene> that's why I'd support only a very minor reduction, to slowly map out tde terrain that's right now unseen
18:16:51 <jeffro256[m]> What would be cool is to have a way to sign an incomplete transaction, missing only the decoys, and send that to a trusted daemon. Upon a reorg X-block-lock deep, the daemon can reconstruct the complete transaction by filling in the decoys and broadcast that transaction instead. Doesn't solve the key image leak problem, but it would increase availability, making those attacks against the network less fruitful 
18:17:51 <UkoeHB> jeffro256[m]: with seraphis you can delegate membership proofs
18:18:43 <jeffro256[m]> Absolutely based, that also fixes cold signing transaction with old decoys 
18:18:53 <hyc> chaserene: the problem with mapping out the terrain is when you reach the limit you've just tanked a $3billion network
18:18:58 <jeffro256[m]> For long term storage 
18:20:50 <jeffro256[m]> hyc: And a psychological effect like that could be very discrete. You would not necessarily see any signs of breakage until you lower it by just one block and then deeper reorgs pop up left and right 
18:22:09 <chaserene> hyc: fair enough
18:23:48 <chaserene> jeffro256[m]: yes, the discreteness of it probably makes it especially to do it safely
18:24:49 <chaserene> * hard
18:25:17 <ofrnxmr[m]> Its a wallet side ux issue that exists as long as we use rings
18:26:16 <jeffro256[m]> Or even full membership proofs, depending on the implementation
18:26:59 <ofrnxmr[m]> I describes an easy to implement wallet sideux feature that gets around it (lockd funds) in probably 99% of cases with minimal privacy reductions from consolidstionsb
18:28:02 <chaserene> ofrnxmr: I'm interested in reading it, where did you publish it?
18:28:07 <hyc> I think the safety issue would go away if txns referenced outputs by their 32byte hash instead of their 8byte output index
18:28:28 <ofrnxmr[m]> twitter
18:29:00 <hyc> then most txns remain valid even after a reorg, as long as they're still mined in the new chain too
18:29:25 <UkoeHB> hyc: the safety issue is that a malicious double-spender can remove their own enotes from the ledger, invalidating txs that reference them as decoys
18:29:57 <hyc> ah, right
18:50:43 <nacrox> i didnt receive a transactions. can someone help me?
18:52:02 <ofrnxmr[m]> Monero  please and thanks
18:53:02 <jeffro256[m]> Or #monero-support:monero.social
19:30:06 <kayabanerve[m]> Rucknium @rucknium:monero.social: There's a few disagreements on how to move forward and a lack of available development 
20:38:46 <chaserene> kayabanerve: what do you mean by "available development"?
21:06:47 <kayabanerve[m]> chaser: Have you implemented SNARKS yet?
21:06:52 <kayabanerve[m]> That's what I mean :p
21:07:21 <kayabanerve[m]> Few people here can and no one has published work yet.
21:08:03 <kayabanerve[m]> I will ask chaser: and Rucknium @rucknium:monero.social: to not contact Bailey at this time though.
21:08:38 <kayabanerve[m]> I don't believe Bailey is an appropriate fit to contact, unless you just want to contact any researcher in the field. Then sure, they're intelligent, knowledgeable, and security focused. Great.
21:09:03 <kayabanerve[m]> They have no direct relation to our needs though. The Curve Trees authors would be a much better choice.
21:09:19 <chaserene> kayabanerve: I haven't implemented any of them yet. I suppose that means none of the existing circuits are a fit for Monero?
21:10:05 <kayabanerve[m]> I'd also ask y'all don't reach out to them though. I've already done so with some replies. I'm still weighing how I want to move forward there, and will sync with the Monero community when I have a path worth discussing.
21:10:43 <kayabanerve[m]> (Or sure, you can be independent and do so. I just don't want to reach out twice and potentially be a bother. That doesn't justify me monopolizing them)
21:11:19 <kayabanerve[m]> To be very blunt, and I'm sorry if I'm too rude as I do, if you're asking that question you shouldn't be reaching out to anyone to organize anything.
21:12:10 <kayabanerve[m]> I don't hold that against you. It just reiterates few people can discuss this at this time, and that limits bandwidth. I appreciate you trying to add bandwidth though.
21:12:45 <kayabanerve[m]> If you do want to try to help, I'd say reading the entire issue, top to bottom, is sane (unlike the TX extra issue which isn't worth the time).
21:13:07 <kayabanerve[m]> There are circuits and proofs which are a fit. We need implementations.
21:13:29 <chaserene> kayabanerve:  okay, noted, and don't worry. I appreciate both your contributions and your honesty
21:13:34 <kayabanerve[m]> narodnik has commented on this work. So have I. There's mutual interest with Firo. jberman @jberman:matrix.org: has bullied me ad infinitum to do it.
21:14:25 <kayabanerve[m]> I'm planning to present, at Monerokon, on this topic, and with it, sync everyone on status. While private/closed doors/black box of me, I'd personally appreciate the opportunity.
21:15:26 <kayabanerve[m]> To at least start that process now, Curve Trees requires a modified BP, which there isn't a formal protocol for nor security proof of. I realized this about a month ago and reached out to the authors asking if they'd be interested in doing so.
21:15:37 <chaserene> kayabanerve[m]: sounds great, looking forward to that
21:17:00 <kayabanerve[m]> They replied with the underlying statements necessary to use Bulletproofs to prove, yet not a protocol using Bulletproofs to do so (though they do have a modified PoC which one can be extracted from).
21:17:33 <kayabanerve[m]> They aren't interested in further work on it at this time, from my understanding.
21:18:58 <kayabanerve[m]> Or rather, they weren't planning to do further work at this time. I've been personally considering explicitly offering funding to do so, as they may be interested if they have the opportunity, yet I'm unsure that'd be optimal at this time. I need to sync with a few people who may be willing to pick it up themselves.
21:21:13 <kayabanerve[m]> And because I haven't done such syncing, I don't feel a need to get everyone's opinion. If anyone has contributing opinions, I'd love to hear them. I just know this aspect is semi-needed (there is a much simpler workaround with much worse performance), so from my perspective, moving forward requires either making the alternative's performance acceptable OR finding someone to do the work. I'm uninterested in trying to organiz
21:21:13 <kayabanerve[m]> authors, or trying to find and organize funding for distinct researchers, when I may be able to arrange for that work to be done myself via another angle.
21:23:53 <kayabanerve[m]> If the other angle doesn't pan out, then we have to evaluate how much worse worse performance is and discuss community organization of research/fundraising. I would absolutely bring that up, likely initially involving MAGIC. I just haven't brought it up since we're now all spending time on it when it's just another few messages I have to follow up right now.
21:24:03 <kayabanerve[m]> (Though yes, there's now reason since others are trying to move forward, which I appreciate :) Just clarifying I have been moving forward. there's just angles and intricacies. I should have a proper summary/path for the community by my self-imposed deadline of Monerokon)
21:25:16 <kayabanerve[m]> And if I didn't have such a deadline, yes, I would've commented much earlier. I'm not trying to prevent other people from hopping in. Solely trying to get some bones down so we don't waste time when we move forward, since I have a definitive time to make such bones or fail to do so.
21:25:45 <chaserene> I think that's all very valuable, thank you for sharing 🙏
21:25:53 <kayabanerve[m]> (There is also a variety of other research aspects. That's my primary WIP rn)
21:28:07 <kayabanerve[m]> Further cc: kowalabearhugs- monerobull: tevador:, and I'm already privately syncing with narodnik and a few other parties.
21:28:07 <kayabanerve[m]> Koe/vtnerd/others would likely also be interested. I just have no actionable reasons to draw them in now, nor am I considering drawing them in yet.
21:30:50 <monerobull[m]> Llama summarize 
21:35:59 <kayabanerve[m]> Literally just I have been privately working on organizing SNARKS a bit more, have nothing worth discussing with the community at this time, and am requesting until Monerokon to present my findings on research and steps forward. That may involve MAGIC/the community coordinating research funding. You were pinged due to that aspect.
22:45:49 <Rucknium[m]> kayabanerve: You are still thinking of it as a software engineering problem instead of as a math problem
22:46:33 <Rucknium[m]> No security proofs yet? Can't move forward without them. At least, cannot go to mainnet without them
22:53:02 <kayabanerve[m]> Rucknium @rucknium:monero.social: I literally said I contacted the authors to ask them about their work, and inquired if they'd formalize/prove it. 
22:53:31 <kayabanerve[m]> My entire commentary was about getting it proven.
22:53:56 <kayabanerve[m]> I also said there was an alternate which wasn't so invasive, just with much less performance. If we can't get the former proven, I'd put forth proving the vastly inferior option.
22:55:17 <kayabanerve[m]> If we can't prove either at this time, then we'd know the obstacles and leave them to be worked on. I never once suggested deploying unproven protocols. I solely discussed getting the protocols proven.
23:12:31 <Rucknium[m]> Thanks. Your summary makes it more clear what your plan would look like.
23:19:09 <kayabanerve[m]> Sorry for being so defensive here. The reason I wanted to wait to post my conclusions, with an explicit path forward already clear, was to avoid these discussions/criticisms/concerns. I do plan to properly comment on the proofs, the protocols, the algorithms, the security of each component, and what they each need. Any in-development view would be partial, as my initial commentary  here was. It's frustrating for me that as I
23:19:09 <kayabanerve[m]> commenting, to prevent seeing wasted efforts, I now have these concerns raised.