ShopinBit Monthly Stats 📊 This month is the highest Monero dominance we've ever recorded: XMR: 81.30% BTC: 15.87% USDT: 1.57% FIAT: 1.07% Lightning: 0.18% Over the last 12 months, Monero led 8 times. Bitcoin 3. Our customers have spoken. Loudly 😎 @monerotopia @MoneroKon @monero @MonericaProject @cakewallet @MoneroMoney @blocktrainer @BitcoinNewsCom @Cointelegraph

🚨ALERT: TETHER FREEZES $72M AFTER $120M MONERO SPIKE EXPOSED EXPLOIT A Tron wallet received $120.2 MILLION in USDT and quickly routed much of it into Monero. The buying pushed $XMR up nearly 30%, helping investigators to follow the trail before Tether blacklisted the wallet.

It's future Motorola devices meeting our requirements which are going to have GrapheneOS support.

Discussion on the proposal was considered concluded. The proposer was reminded of final paperwork steps to make the proposal public-facing on the funding-required page. rucknium: I think discussion on this has concluded, but just put it here just in case. rucknium: yiannisbot yiannisbot: Hi everyone! rucknium: Just some paperwork things: You should remove the strike-through formatting and get it ready to go here: ccs.getmonero.org/funding-re… rucknium: We know what edits were made because it's a git repo. rucknium: And maybe ofrnxmr and plowsof want to reevaluate their thumb votes on the proposal since they spoke approvingly of it most recently. rucknium: I mean you need to get the body ready to be public-facing. Potential donors see the proposal body and evaluate it. yiannisbot: Agreed. Wanted to make it easier to spot changes, before we proceed. Will do final edits by tomorrow. rucknium: Thank you. rucknium: yiannisbot: AFAIK, you can finalize the process with ofrnxmr and/or plowsof libera.monerologs.net/monero…

Referencing prior discussion, the MRL agreed the topic should not return to the agenda without a formal writeup or proof-of-concept. The issue was recommended for documentation as an informational footnote in the CARROT spec. rucknium: This was brought up last meeting. Do we want to discuss this issue? jbabb: I don't see our relevant "fraus bug"/view-all evasion CS researchers online and I think the conclusion from the last discussion, that it shouldn't be re-added to the agenda without a writeup and/or proof of concept, fair. I agree that it requires not adhering to the CARROT spec and it isn't a CARROT-specific issue, it affects legacy view keys, too, and hinges on CARROT re-using legacy view key properties jbabb: it is a way to hide things from view keys by not doing things in the way you're supposed to and think it's safe to move on until we/CS share more code jbabb: the conclusion to stress was that we should not and can not claim that we have "view-all" keys that make monero safe for eg. KYC/AML compliance purposes jeffro256: I think that it's a good informational issue to be documented somewhere. I also planned for the view-all tier to be opt-in, but I can see how that would be confusing / concerning to a third-party who expects the view-all properties to hold unconditional on the viewed entity's behavior. jeffro256: I always planned jbabb: the new carrot view keys do not guarantee exchanges can see safely view all customer activity rucknium: Oh sorry I struck out the wrong agenda items that didn't have write-ups, either. jeffro256: I mentioned this to BG, but it would make a good footnote in the CARROT spec, yeah? Exactly how to break it, how to make sure the view-all properties can stays intact with further info, etc ... jbabb: ... any more than the legacy view keys. however of course the new carrot view keys enable great UX eg for hardware wallets, so I'm excited for it, especially now that the doomerism that "all exchanges will require these new keys" is a technical non-issue (we can lie to the view key) jbabb: (also you could always just hop one wallet away--much simpler) jbabb: Sorry, that's all on the topic. UkoeHB: jeffro256: the view-all tier accompanied by a thorough (well-implemented) audit is unconditional (would have to think hard on if you can make such an audit with just the view-all key, which would make that key functionally unconditional). Unviewable enotes would be isolated from viewable, making them essentially in a separate wallet. tevador: "view-all" is really "view-all-within-specs" UkoeHB: jpk68: everything needs to remain at least minimally supported for existing users jpk68: So once there are no users (i.e. when we switch to full PQ), then it's unneeded? tevador: It's needed to restore legacy wallets, at the very least. libera.monerologs.net/monero…

Block size stress was increased to the short-term median of 6MB. The main spamming server experienced an outage (cause unclear). Daemons remained stable overall, though peer banning occurred with tripled hashpower. Ongoing work includes higher-frequency ban investigations, pool fetching optimizations, and upcoming p2p SSL integration for the next beta. rucknium: I pushed up the stress to 6MB blocks, which is the short-term median. But in the last 24 hours the main spamming server has had an outage. rucknium: I hope I didn't accidentally cause the outage, but it's too early to tell now. jeffro256: rucknium: Thank you for doing that jberman: jeffro256: Yep, this does seem to be the case to me. I'm looking into higher frequency bans, and jeffro's latest optimizing pool fetching (should help both daemons and wallets when the pool is large) jberman: And vtnerd's p2p SSL is in the wings right now, we can aim to have that in next beta release libera.monerologs.net/monero…

Monero-PSK, presented as an alternative approach for static addresses with one-round offline payments, was already under active discussion from the preceding agenda item on Jamtis protocols. The group agreed to defer further substantive review until spirobel prepares a formal draft proposal. rucknium: Next agenda item is supposed to be Monero-PSK. It's being discussed now, so: rucknium: 5. Monero-PSK (gist.github.com/tevador/9169…). rucknium: Should we return to it when spirobel has a draft proposal? tevador: If spirobel's wallet also supports static addresses, I don't think it can be done without scanning. And after restoring from a seed, you can't be sure no static address was ever used. So in the end, you end up with something very similar to Jamtis ISP. spirobel: yes. good idea. I am still busy with other work atm. spirobel: I also want to state that this is not an either or discussion vs jamtis. So there is no need to debate this like a life and death situation :D jpk68: Unfortunately, I don't think Q-Day is going to wait with you spirobel: jpk68: trust me. it will be done before the quantum puter arrives and tells us the answer is 42 :) spirobel: and it will be possible to use it in a PQ secure way jberman: spirobel: It's ideal for the entire Monero ecosystem to have a standardized protocol for transacting. It's also beneficial to have a complete picture of protocol options before settling on an address protocol tevador: There is no way to do a static PQ secure address without a PQ key exchange. Prove me wrong. spirobel: jberman: then lets agree to disagree here. no urgency to this. and no way to force this 400 bytes addressing protocol on everyone jpk68: It can fit in an IRC message and that tevador: spirobel: 400 characters* tevador: Good luck designing a shorter PQ secure address (with static address support). libera.monerologs.net/monero…

tevador presented the Interactive Payment Protocol (IPP, Appendix B) and Instant Sync Protocol (ISP, Appendix C) from the Jamtis draft appendix. Discussion focused on UX of multi-round message exchanges, blockchain restorability of IPP payments, challenges of direct wallet-to-wallet data exchange (compared to multisig), static address support, hybrid encryption as mitigation for post-quantum risks, and alternatives including public key sharing infrastructure or Monero-PSK. tevador: I have published the interactive payment protocol (IPP) and the instant sync protocol (ISP) in the Jamtis draft appendix. I'd like to discuss these today. jberman: My opinion on the ISP is that I don't like the UX and am pretty eh on its inclusion in the spec as its a tacit encouragement for wallets to implement it jberman: But it's a cool idea and I respect that it's 0 added cost on addresses / chain space jeffro256: Re: UX, I would assume that wallets can implement this exchange automatically. Bob and Alice wouldn't actually be copying and pasting messages 4 times jeffro256: I mean, you could if you wanted it to be airgapped ig rbrunner: Hmm, isn't this the same problem as with multisig data exchanges earlier: wallets can't directly see each other? tevador: Note that jberman is speaking about Appendix C, while jeffro256 is speaking about Appendix B jberman: ^ jbabb: Jamtis-ISP > Monero-PSK jeffro256: Oh oops, sorry, yeah I was talking about IPP tevador: Yes, Appendix C was added in response to the Monero-PSK proposal tevador: It's the closest thing we can do with Jamtis jberman: One thing to be clear about for IPP: is there a way to restore an IPP wallet from blockchain data? I was under the impression that wasn't the case, but the spec isn't perfectly clear on that rbrunner: Exchanging data directly between wallets is a problem that I thought long and hard and found no easy and straightforward way jeffro256: rbrunner: Are you taking about IPP or ISP? For IPP, you wouldn't need a transport layer with long-term storage like Bitbucket since messages can fail at any point and you end up okay. Whereas the same can't necessarily be said about multisig. Also you only need 2-way comms, not N-way comms tevador: jberman: the interactive payment is restorable from blockchain data (as an internal payment) spirobel: yes and there is another way to do it in one round. so wallets can be shared publicly and users can directly send the tx without having to wait for the other party to be online jeffro256: *bitmessage rbrunner: jeffro256: Data exchange between wallets quite in general. If if only "both online" and "only 2 way", how would they find each other? rbrunner: *Even if only ... spirobel: i am not a fan of jamtis. and pushing it down everyones throat. but i dont want to stand in your guys way if you want to implement it spirobel: i personally dont want to use it because i think this pq crypto is too new and unproven spirobel: people can just use signal or other messaging apps and treat the addresses as secret key material jberman: Aka public key sharing infrastructure? rbrunner: Well, standing up to a task, actually producing something, and then proposing it, is not "pushing it down my throat" in my book jeffro256: Lots of ways. For example, if a merchant has a website that you interact with anyways, you could use a HTTP API (hopefully somewhat standardized) tevador: "PQ crypto new and unproven" - that's why we have hybrid encryption, IMO that's not a real reason against Jamtis. rbrunner: Exactly, let's standardize something :) spirobel: jeffro256: yes i am currently working on exactly this. i have a few endpoints already specified and working. jberman: jeffro256: Specifically for the case of friend wants to pay a friend e.g. not a merchant payment jberman: Or merchant hasn't set up a server tevador: "people can just use signal" - good luck doing that with a static donation address jpk68: I think having to use public key-sharing infrastructure is way more of a UX hurdle than, say long addresses with Jamtis jpk68: Look at how unusable PGP is for the average person rbrunner: Getting something accepted as new standard in our, well, quite chaotic ecosystem, is a bit of a challenge, me thinks ... rbrunner: me thinks jberman: tevador: And with the scheme, as soon as you share a static address from your wallet, your wallet then has to scan the chain into perpetuity to identify receives rucknium: Is anyone very familiar with BitPay? I think they have wallet-specific interaction protocols for BTC and other coins. spirobel: rucknium: no idea never heard of them jberman: Lol spirobel: jberman: i want to add messaging functionality anyway. so there is the possibility to do it automated and standardized but the user is not forced to. they can also send the receiver a snippet / link over any other (encrypted) chat app / email spirobel: jpk68: yes its not good. so we have to do better jberman: Automated = via a messaging server in the middle jeffro256: If neither of you run a server of your own (e.g. you're both on mobile), and you're okay with bouncing messages off another server, Websockets is a good option tevador: jberman: my response was directed to spirobel, who thinks we don't need to support static addresses at all (see Monero-PSK) spirobel: no use to private payments if people communicate non encrypted or over centralized services all the time rucknium: BitPay as a whole model isn't very good because they require a lot of controls. I think they did KYC of consumers for merchant txs in some jurisdictions. jberman: Lol jberman: spirobel argue your case why Monero should get rid of static addresses tevador: Jamtis ISP is a way to get instant sync while still supporting static addresses (with the caveat that you lose instant sync if you use a static address) rucknium: BitPay is big. So get familiar maybe spirobel: jberman: i never made this case. i am saying that there should be the option for people to have addresses that dont require syncing. and there should be the option to have static addresses where the sender notifies the receiver out of band, and the receiver then notes down the channel opening so he can recover from seed jeffro256: If you are in-person, RFC payments spirobel: and my case is: there is no contradiction to jamtis there you guys can do your pq stuff with 400 bytes addresses and i do my stuff spirobel: no need for this discussion rucknium: bitjson, who does a lot of Bitcoin Cash protocol work, used to work at BitPay: github.com/bitjson blog.bitjson.com tevador: Everyone can do their stuff, but the official software cannot support everyone's stuff. jberman: spirobel: So receiver has to have info saves from the channel opening in order to recover from seed = receiver can't recover instant sync from seed alone jberman: Saved spirobel: jberman: yes the receiver can recover from seed. both can recover from seed jberman: How can the receiver recover from seed alone in that case? tevador: If someone needs to post a static address somewhere, Jamtis offers better long term privacy than a legacy address. spirobel: jberman: by finding the channel opening the receiver noted down as i mentioned jberman: How do they find it from seed alone? rbrunner: So that's "from seed", but not "from seed alone"? tevador: jberman: We've been asking spirobel for a draft proposal for a long time. All I've seen are hand waving arguments. spirobel: by noting it down in a tx. in both cases a secret that is derived from seed is embedded in a tx so it can be found later jberman: I've also seen insults and poor logic spirobel: doesnt matter who writes it spirobel: i dont know what your point is just move on spirobel: the logic is very simple tevador: The proposal needs to be written by someone who knows the solution, which only seems to be you. jberman: This is an interesting idea. A scheme expanding on this and explaining how it works would be interesting to read rbrunner: What speaks against a draft proposal? Things still in flux? Lack of time right now? spirobel: yes i will write it down and build a poc once I have more time spirobel: the issue with being unable to tell if an address hasnt been used doesnt exist with public / static addresses. it is not like jamtis isp as it requires only one round and the two parties dont have to be online at the same time. thats it tevador: spirobel: you confused Jamtis IPP and Jamtis ISP. Jamtis ISP works offline after an initial 1 round setup. tevador: spirobel: of course the problem exists with static addresses. Addresses that have once been published may not stay published forever and you can't know who's still keeping them. jpk68: Sorry if this sounds rude, but once something like Jamtis is no longer in use, is it possible to remove the user-facing code for it from the codebase? I guess this would apply to Carrot as well. It seems like needless attack surface if it's not in use anymore jpk68: For example, in the wallet implementations tevador: spirobel: of course the problem exists with static addresses. Addresses that have once been published may not stay published forever and you can't know who's still keeping them. UkoeHB: jeffro256: the view-all tier accompanied by a thorough (well-implemented) audit is unconditional (would have to think hard on if you can make such an audit with just the view-all key, which would make that key functionally unconditional). Unviewable enotes would be isolated from viewable, making them essentially in a separate wallet. tevador: "view-all" is really "view-all-within-specs" UkoeHB: jpk68: in the case of moving completely to PQ? Sends to Jamtis addrs would no longer work, whether or not there is user-facing code. jpk68: ukoehb: Yes, I understand that. I just mean that, for example, it seems there would be not much point in having carrot_core/carrot_impl if Carrot isn't being used anymore (and is somewhat unrelated to consensus rules). I might be misunderstanding something UkoeHB: jpk68: everything needs to remain at least minimally supported for existing users jpk68: So once there are no users (i.e. when we switch to full PQ), then it's unneeded? tevador: It's needed to restore legacy wallets, at the very least. jpk68: Ah, I forgot about that. Thanks. jeffro256> sech1: should we discuss including the number of txs in the block header hasing blob in v17 in next week;s meeting? tevador: Do you mean excluding? AFAIK it's already included. libera.monerologs.net/monero…

.@MagicGrants received seven audit quotes ranging from $15,000 to $100,000. The $35,000 option was recommended for its balance of cost, experience, and value. After discussion of the 24-hour notice rule, start date availability (potentially late June), and input from key reviewers, the MRL agreed to proceed with the $35,000 quote pending final confirmation on dates and additional reviews. sgp_: MAGIC Grants has received 7 quotes ranging from $15,000 to $100,000 sgp_: The $15,000 one would be an honest review, but I recommend a review for $35,000 since the auditors appear to have more experience. It seems like the best compromise between cost and skill sgp_: Jeffo, Luke, and Berman can also add their comments if they like sgp_: I would like to get approval during this meeting to go forward with the $35,000 one as the selected option sgp_: unless people strongly feel that it's best to select the cheapest one, or have other opinions jberman: I second that opinion, $35k quote appears the best value tevador: 1 for the 35K quote rucknium: Did we get 24 hours notice on the H/S reviewer options? rucknium: I don't want to delay, but I am wondering why we have this informal rule that is being broken more often than followed. Or did I miss a prior message? sgp_: I thought I posted it here earlier but I guess it was only this morning. Long day jberman: We have 2 layers of beaureaucracy now for managing audits, and multiple audit tasks in flight. I don't fault sgp on this. We have been discussing the candidates internally as well jberman: rucknium: Yes sgp_: I do fault sgp on this :p tevador: Any info about the lead time on the audit? jberman: 35k candidate was also my number 1 prior to this meeting jeffro256: SGP sent info last week, but I just haven't gotten around to analyzing it deeply, sorry sgp_: tevador: Give me one sec to double check tevador: OK, it means they will probably start without a delay sgp_: Hopefully so. Before finalizing acceptance with them, I will get clarity on the new start date and ensure it's acceptable to berman, jeffro, luke tevador: Does anyone object to going with the 35K quote? sgp_: fwiw, MAGIC Grants hired the same auditor for the June 8th slot because that other project moved a bit faster. Let me check when that ends; that end date might be the most likely new start date sgp_: that project is June 9 to 29. So if they can't do concurrent with different team members, then possibly a June 29th/30th start rbrunner: I am not sure about accepting ... we have now only statements from sgp and jberman, if I followed correctly. Would be assuring to have at least 1 more IMHO sgp_: fwiw, I don't think this review is blocking anything, at least strictly speaking. It's something that needs to get done, but there's no expected work that is waiting on this afaik jberman: End of June start date would be acceptable to me sgp_: jeffro256: do you have time to review it now? tevador: There would be 2 reasons to postpone: 1) the 24h notice and 2) giving jeffro256 time to review it jeffro256: The firm for 35K is one that I have never worked with directly, but I have heard good things about them rbrunner: Let's say I don't oppose :) sgp_: let's just wait then. Ideally luigi could be ready to go after the meeting rucknium: Sounds good. Thank you for arranging things. jeffro256: Yes, thanks sgp_ rbrunner: 1 libera.monerologs.net/monero…