11:20:25 Hello, I am planning to develop an XMR-based stablecoin capable of multi-chain conversion to USDT/USDC (non-KYC) across popular blockchains such as TRX, BSC, Polygon, Avalanche, and Solana. Who within the Monero team should I contact for support with this project? 11:38:13 Well, for years already and to this day the topic of the monero-dev IRC channel contains the following info: "No fork help, you’re on your own" 11:41:41 And "stablecoin" is some kind of a "red rag" for many people around here. So maybe expect some uphill battle :) 11:43:23 Maybe a long shot, but check this project, to join forces? https://serai.exchange/ 11:45:46 @mrphamlong:matrix.org: You can deploy a MoneroSwap contract on Stable chain, you will have instant availability of atomic swaps between USDT0 and XMR, through ustd0.to you can bridge from/to other chains 11:47:15 @rbrunner7: Are there any stablecoins on the Monero network? Or does this service only support converting stablecoins from other blockchain networks into XMR? 11:47:56 @mrphamlong:matrix.org: The Monero blockchain doesn't have the ability to create other coins, it is only used for XMR 11:50:52 Never heard about that "MoneroSwap contract" so far. True atomic swaps between USDT0 and XMR, you say? Is that live for a long time already? With useful liquidity? 11:55:35 @rbrunner7: been working on it for over two years. 11:55:35 https://ccs.getmonero.org/proposals/hbs-evm-atomic-swaps.html 11:55:35 https://youtu.be/cUYUuoPJNsI[... more lines follow, see https://mrelay.p2pool.observer/e/wuvM-p8LYmpicUs0 ] 11:57:25 Ah, I see, wasn't properly recognizing USDT0 as something on Ethereum :) 11:58:02 Or better said, running on anything EVM 11:58:34 @rbrunner7: It's unified USDT0 across chains 15:01:34 MRL meeting in this room in two hours. 15:02:19 Speaking of: https://github.com/monero-project/meta/issues/1440#issuecomment-5268558581 15:05:21 https://mrelay.p2pool.observer/m/monero.social/wWIsAyUJuevFsyezYcOsfDTR.gif (9zsjcz.gif) 15:05:31 @rucknium: ^ 15:47:51 sech1: Thanks. I will add it at the end. 15:49:07 @rucknium:monero.social can we delay meeting there is an incredible eclipse going on right when meeting begin 15:49:47 i can say hi to the eclipse for you 16:05:09 @syntheticbird:monero.social: No 17:00:39 Meeting time! https://github.com/monero-project/meta/issues/1440 17:00:45 1. Greetings 17:00:56 waves 17:01:05 hi 17:01:10 Hi 17:01:12 hi 17:02:07 Hello 17:02:55 2. Updates. What is everyone working on? 17:03:25 Good afternoon legends 17:03:44 I'm working on adding FCMP++/Carrot/RandomX v2 support to P2Pool, this will take a few weeks and I'll probably be more active in the meetings during this time 17:03:51 Howdy 17:03:56 Hi 17:04:36 Me: working on bug fixes and reviewing upstream PRs, and generally trying to get the FCMP++/Carrot merges through 17:05:07 me: various PR's to monerod upstream / reviews, updated subsequent FCMP++ integration PR's (the next few in a row are ready to go) 17:05:17 me: fixed + unit tested a bug in lws (after fixing another issue), and got my guix setup with signing key ready for 0.19 bootstrappable builds 17:05:26 me: Writing scripts to analyze network-level transaction privacy using monerosim. Finding an reporting issues in monerosim: https://github.com/Fountain5405/monerosim/issues . Keeping stressnet stressed. 17:05:34 I think this week I'm going to switch back into working on Carrot coding tasks like hot-cold and knowledge proofs, now that some big refactor/review PRs are out of the way 17:05:45 me: still need to work on a bug for selsta, and the d++ privacy leak discussed last week 17:06:10 Me: working on a validator for pending_tx (multisig and cold signing workflows) 17:06:41 Me: trying to fix some hardware wallet bugs 17:07:41 3. PQ turnstile spend enables a Carrot/Jamtis distinguisher (privacy leak) (https://github.com/jeffro256/carrot/issues/10). 17:08:52 Maybe jeffro256 can comment. It's possible we can just accept the leak. But the fix is relatively cheap IMO. 17:09:32 Sorry for not answering, I have been looking into this and I think that, since the Carrot code has evolved since I originally unbound K^j_v, the original suggestion of re-including K^j_v won't add too much complexity. I will have an enginneed solution by EoW 17:09:55 Thanks 17:11:13 I think we can move to the next agenda item. 17:11:41 4. FCMP++ to-do list status. Programming tasks (https://github.com/seraphis-migration/monero/issues/53). Reviews and audits (https://cryptpad.fr/sheet/#/2/sheet/view/yPVIUywwA9-deE9VF6GYm9bXbPdCerdST3UDEEfBxcM/embed/). FCMP++ Integration Audit Overview (https://github.com/seraphis-migration/monero/issues/294). Network upgrade [... too long, see https://mrelay.p2pool.observer/e/usfSg6ALYkIteVRY ] 17:12:37 The Rust FFI PR was merged into upstream master (hooray), next on the FCMP++ integration list is: https://github.com/monero-project/monero/pull/10360 17:12:50 That is the final PR from the Phase 1 FCMP++ integration audit 17:13:38 I have updated the planner here: https://html-preview.github.io/?url=https://github.com/jeffro256/fcmp-carrot-plan/blob/master/fcmp%2B%2B-carrot.html 17:13:51 OOps that's already linked 17:14:21 For Phases 2 & 3, right now I'm thinking it would be best to just keep going reviewing on our end and merging code, and once all code is in we audit then (perhaps we get Phase 2 audited once all that code is in). I think that would be most efficient 17:14:59 Biggest blocker on the Carrot side seems to be licensing around mx25519: https://github.com/monero-project/monero/pull/10964. tevador has mx25519 licensed under LGPL, which has some restrictive terms. 17:16:46 No major update at the moment on the final Research Task audits. The Least Authority helioselene audit is very close to the finish line 17:17:21 There's some discussion around how exactly Monero will comply with the terms in section 6 of LGPL v3: https://github.com/monero-project/monero/pull/10964#issuecomment-5208353737. IDK if anyone has something to throw in here, because it doesn't seem to be going anywhere quickly... 17:17:23 And we still need quotes for divisors impl audit rd. 2 + fcmp-plus-plus lib audit 17:18:23 @jeffro256: It does seem like this would complicate things a fair bit, which would be quite inconvenient. Adopting LGPL dependencies, I mean 17:18:40 The amount of complexity surrounding this upgrade is already pretty extreme 17:19:35 Downstream users of Monero code would also be affected by this (i.e. wallet applications) 17:19:48 The "restriction" of LGPL § 6 would imply we would need to provide a link to the tag commit the release was built from. Which is hardly a restriction. 17:20:36 tevador: You mentioned that you didn't want to relicense your code after companies made proprietary forks of RandomX code. 17:20:38 Example: https://github.com/monero-project/monero/tree/v0.18.5.1 17:20:39 Yeah, that does involve some changes to monero-site, though. 17:20:50 I'm wondering how the same concern applies to general cryptography code, rather than PoW 17:20:54 the primary objective of the lgpl is to force changes to mx25519 to be made public … ? 17:21:15 Yes, but how is that practically relevant here? I can see how it is for RandomX 17:21:40 The exactly same thing applies to a Curve25519 library. If someone makes optimizations, we want to be able to upstream them. 17:21:42 I guess a wallet could be made faster in secret, similar to the issue in randomX 17:22:02 In xmrpay-carrot I already use a BSD-3 Rust implementation based on curve25519-dalek that matches the upstream CARROT vectors. 17:22:31 It only covers the receiver side CARROT operation for now, not the full mx25519 API. 17:22:31 would a permissively licensed rust implementation be useful, or does Monero specifically need C/C++? 17:23:07 c/c++ is more useful to the project I think, but opinions may differ 17:23:18 I'm pretty sure mx25519 is faster than curve25519-dalek 17:23:34 But both are usable for a wallet implementation 17:23:40 Espeially after considering Rust FFI 17:23:52 *Especially 17:24:11 hmmmm 17:24:11 what about a small portable BSD-3 C/C++ implementation be useful as a starting point if it matches the full unclamped API and existing vectors, or would optimized amd64/arm64 backends be required from the start? 17:24:23 just wondering if I can be of any help 17:24:58 this is assuming we are rejecting lgpl for some reason, it doesn’t seem to be a clear consensus on that 17:25:04 If you can get a portable implementation as fast as the amd64x version, I'd be impressed 17:25:07 A portable permissively licensed implementation could be made quite easily from the ref10 public domain code. But it's quite slow. 17:25:10 every wallet is open source already, if Im not mistaken 17:25:35 LGPL is open source. 17:25:53 @jeffro256: I’ll try my best 17:26:16 I meant a wallet trying to use mx25519 but closed source somehow. I’m just not seeing any reason to worry about lgpl but maybe Im missing something 17:26:26 LGPL § 6 is not the only restriction and its restrictions would apply to all downstream projects, not just Monero. 17:27:01 LGPL is incompatible with the CoC: "All contributions to the project source code ("patches") MUST use the same license as the project." 17:27:15 This is my point, we have already had enough trouble trying to get, for example, hardware wallet companies to integrate Monero 17:27:28 Making licensing matters more complicated is shooting ourselves in the foot 17:27:31 I’m not assuming LGPL will be rejected. I’ll treat this as a small benchmark experiment first, compare it against the portable and amd64x implementations, and only suggest it if the result is actually useful… 17:27:31 I’ll start working on it 17:27:53 The CoC is clearly meant for other cases, like someone submitting a random patch under GPL. 17:28:47 AFAIK we already have at least one LGPL dependency 17:28:56 Also, the LGPL wouldn't prevent proprietary freeloading, since they could link dynamically 17:29:11 IIRC the only "copyleft" library we use currently is ZeroMQ, which is MPL 17:29:27 That's somewhat less restrictive compared to LGPL 17:29:50 "The CoC is clearly meant for other cases" <- I don't agree. Quoting myself from the issue: "If we allow non-permissive licenses in required dependencies, the rule becomes meaningless: contributors can just work around the rule by introducing code with a non-permissive license via a submodule, which is what is happening here." 17:30:33 whats the other lgpl depdendency? polyseed? or something else 17:31:23 Quoting myself from the issue: "It's clear that both libraries are non-trivial and usable outside of the Monero repository. I didn't implement them to circumvent a rule." 17:31:29 The other one is polyseed 17:31:31 > Also, the LGPL wouldn't prevent proprietary freeloading, since they could link dynamically 17:31:31 It would prevent modifying mx25519 itself, and not publishing the modifications, which is the point 17:34:08 More discussion on this issue? 17:34:53 Ideally, we should figure this out soon, because it is a blocker for Carrot and Polyseed support 17:36:25 Can the licensing discussion be moved to No Wallet Left Behind #no-wallet-left-behind:monero.social meetings or should it stay here for next week? Or moved back to GitHub? 17:36:28 tevador: do you see yourself budging on this issue and relicensing? 17:36:51 I will honor a vote 17:37:13 tobtoht: Since we have maintainers and approval processes, it is always at our discretition to block the changes that are superfulously adding non-permissive licensing for their own sake. I don't believe that Polyseed and mx25519 are those cases. 17:38:47 We will need to do some infra work on the monero-site side to support LGPL license terms. Is someone willing to make those changes? Also, we need to implement a license command or something along those lines correct? 17:39:04 To display the license body from the object code 17:39:55 @rucknium: If the relevant people will join NWLB on Monday, then it could be moved there 17:40:54 my opinion on this is whatever moves this forward as fast as possible, I don't have a strong opinion on the license discussion itself 17:42:14 I think we should move on and if tevador wants to add to above tevador can 17:42:25 jeffro256: AFAIK we could just add the license file(s) to the release archive. 17:42:46 I have already explained why I'm not going to relicense. 17:43:20 ok, if tevador isn't going to relicense then I think let's just find a way to move forward with that 17:43:48 My personal opinion is that we should not burden every downstream ecosystem project with a restrictive license. 17:44:51 I think that's a fine opinion but we're stuck at an impasse here and I think it's best we move forward with it 17:45:44 The "restrictions" of LGPL are quite mild, even for closed-source projects that use the library. 17:45:44 I am also against restrictive licenses both on principle and pragmatically (how much time wasted already on this? MIT gets no such drama). Is it possible an LGPL fork will just patent any changes they make, rendering the whole endeavor meaningless? 17:46:06 What exactly is the burden for downstream eco? That they must point to the Monero source ? Does that resolve section 6 since our repo would point to mx25519? 17:47:16 AFAIK there was no issue until tobtoht started to dispute the license. 17:47:53 I don't want to be annoying and keep insisting on not having permissive licenses (at the expense of delaying things), but I feel like it's not a great idea to keep making non-ideal decisions, causing later technical debt, for the sake of finishing things faster 17:48:19 TBF looking over license terms is exactly what we need to avoid licensing issues ... 17:48:59 At some point, one has to wonder how many concessions we're willing to make (Rust, LGPL, etc.) just to jam things through quicker 17:49:02 in this case I don't think there is much room for significant issues either way and both sides raise fine points 17:49:28 yes yes just to jam things through quicker than the 2 and a half years this has taken 17:50:13 Given tevador 's statements, isn't a clean-room reimplementation of mx25519 the only way to avoid the LGPL in the Monero codebase? Anyone want to do that? If no, there seems to be only one option. 17:50:20 @jberman: Rewriting FCMP++ code in C/C++ would probably take longer than using the Rust library, no? 17:50:30 absolutely not 17:50:31 AFAICS the only change that would need to be made is to add the (L)GPL text to the release tarball. The rest is already solved. 17:50:39 sorry, absolutely yes* 17:50:42 Any code rewrite will require another code audit 17:51:50 tevador: Does does downstream have to do this if they use Monero as a library, instead of downloading releases? 17:52:01 My point is simply that we shouldn't keep making compromises which will incur future technical debt under the excuse of saving time. In other words, I agree with tobtoht here 17:53:36 IMHO, this issue should go on No Wallet Left Behind's agenda next week. 17:54:10 jeffro: It depends if they use the part that links to mx25519, then they have to also include the license file. 17:54:36 Let's continue. 17:54:41 5. Relative locks with FCMP++ (https://github.com/monero-project/research-lab/issues/161). 17:54:58 I'm not going to rehash the argument over Rust for the millionth time fwiw, I don't think you're raising a valid point there and it's frustrating to keep bringing it up in contexts like this. It's (an invalid) negative framing that doesn't need to be re-argued every other conversation 17:55:17 Last we left this, koe said: 17:55:17 > < UkoeHB > I think we should get a prod-oriented PR for the change and aim further discussion at that. 17:56:28 Do we have a prod-oriented PR for relative locks? 17:57:58 This PR needs a review: https://github.com/seraphis-migration/monero/pull/445 17:59:40 UkoeHB: Any comments on relative locks for now? 18:00:56 no, I will add review for 445 to my list 18:01:08 Thanks. 18:01:28 6. Shi, Zhang, Ge, Lan, Zhang, & Wang (2026) "Deanonymizing Monero Transactions in Tor Network." (https://arxiv.org/abs/2607.07062) 18:02:31 In his update, vtnerd said the Dandelion++ privacy leak was on his to-do list. > <@vtnerd> me: still need to work on a bug for selsta, and the d++ privacy leak discussed last week 18:03:11 Last meeting, @boog900:monero.social suggested that discussion of this PR be revived: https://github.com/monero-project/monero/pull/9295 "Fix embargo timeout in dandelion++" 18:04:03 and possible hardening of when certain messages can be sent, that was specifically used as a vector to run timing analysis 18:04:17 I've started to write some code that can analyze the resistance of the tx relay protocol to spy nodes, using monerosim. I had in mind possibly doing a comparison test with and without PR #9295 18:05:29 I'm not sure if I should run the simulations with tx relay v1 or v2. @jberman:monero.social or @boog900:monero.social , do you have any opinions or info on when tx relay v2 might be deployed to mainnet? 18:06:15 @boog900:monero.social reviewed the latest changes to tx relay v2 here: https://github.com/seraphis-migration/monero/pull/450 18:06:27 In theory, there shouldn't be a big difference in the privacy of v1 and v2, but I would want to test what's most reasonable. 18:06:44 I think we will want to get that tested in beta, as testing uncovered the issues that PR solved (including with a change to the p2p messaging protocol) 18:07:31 I was going to raise this in discussion of stressnet, but with that review, I think that gives the green light for including those changes in tx relay v2 and moving forward with them for beta 18:08:55 Thanks for the info. I think I will start with v1 because deployment of v2 seems to be a little further in the future. 18:09:27 More discussion of this item? 18:10:19 @boog900:monero.social also raised the point that this PR should help as well: https://github.com/monero-project/monero/pull/11048 18:11:09 which should land in next release (I'd figure it's maximally helpful when the whole network is running it, though) 18:11:31 from the description, it does help 18:11:32 By the way, the simulation analysis is going to have to handle some interesting statistical issues to separate the noise of different simulation seeds from actual true differences in privacy levels of any proposed change. I will look into it myself, but input from others is appreciated. 18:13:36 7. FCMP beta stressnet (https://github.com/seraphis-migration/monero/releases/). 18:14:01 The people cry out for a new fork from testnet :D 18:14:30 @rucknium: indeed 18:14:31 I can’t wait xd 18:15:06 Yes looks like people want a fresh chain, and @jeffro256:monero.social 's idea to raise the min penalty fee zone to current stressnet's max block size to allow for larger blocks right away seems reasonable to me 18:15:21 yay 18:16:16 With boog's green light on this PR https://github.com/seraphis-migration/monero/pull/450 , I think now we should be good to have all code for a beta v3 ready 18:17:08 So will aim for next week to have latest master on the beta stressnet branch + a new v3 ready to go 18:18:01 @jeffro256:monero.social we could maybe reuse that logic from v2 to have nodes auto pop back to the prior fork height 18:18:10 I may halt my spammers on the current stressnet. 18:19:51 I can turn this into the v3 checklist and people can follow along there as we knock out the tasks: https://github.com/seraphis-migration/monero/pull/415 18:20:46 crap my ssl patch needs another rebase, adding that to my list this week 18:21:28 I think maybe wait til we have all of master in to avoid another round of conflicts 18:21:40 ok 18:23:11 Anything more on stressnet? 18:24:41 8. PoW-Admitted Zero-Fee Transactions for P2Pool (https://gist.github.com/SChernykh/aae5b2d414095e742437134ab20d4353). 18:24:51 sech1 18:24:53 In a few words: I think I found a way to introduce 0-fee transactions without their downsides (tx spam), by requiring PoW for them (PoW solutions are cryptographically bound to each tx). Read the link above 18:25:20 The main purpose is to use them for miner payout consolidations 18:25:31 and to add more incentives to mine with P2Pool 18:25:45 Are these txs broadcast throughout the network, or only accepted in the txpool of nodes that have a p2pool miner attached? 18:26:01 They are broadcast through P2Pool network layer, not Monero 18:26:16 P2Pool only sends mined blocks to monerod (blocks with 0-fee transactions, if any) 18:26:38 OK. I read the first two sections, but I did not remember seeing a clear statement on that. 18:26:59 monerod doesn't accept/relay such transactions, so it's the only way 18:27:09 Doesn't that slow down block propagation because those txs need to be requested instead of pure fluffy blocks propagation? 18:27:40 hmm, it does 18:27:55 By how much - it's another question that will need testing 18:28:12 For p2pool consolidations, you can also do it with out PoW by having the p2pool nodes build a set of all p2pool outputs, then attaching FCMPs on the side of the tx that prove the inputs are in the set of p2pool outputs. This, of course, leaks that the tx is a consolidation tx. 18:28:28 Note that 0-fee transactions as described are already possible already today, just no one does it. P2Pool proposal just makes it more viable to use. 18:28:59 jeffro256 I think DataHoarder is looking into this 18:30:11 The consolidation tx may be quite large, 128-input FCMP++ is ~180 KB. 18:30:12 I am and reimplementing some stuff yes. Even aggregation of outputs (but that is more complex) 18:30:41 Yes, consolidation tx are large, but they will happen anyway because P2Pool miners do need to use their mined coins 18:31:10 The proposal just exchanges monetary fee with a PoW fee (electricity, time spent) 18:31:53 My point is that each node at each hop will need to download 180 KB from the sending peer, slowing block propagation. Maybe it's acceptable. 18:32:21 You could have all nodes accept these txs so that block propagation would not be delayed. But that's risky because a flaw in the p2pool implementation side could open the door to malicious spamming throughout the network. 18:32:55 Don't forget that P2Pool submits mined blocks to all its nodes, and 0-fee tx will also be submitted to all P2Pool nodes at the same time 18:33:03 which limits the number of hops to the entire Monero network to 1-2 18:33:36 Because all P2Pool nodes will mine the same 0-fee tx once its broadcasted (through P2Pool network) 18:34:14 Mining pools could attach p2pool to their nodes that produce block templates to speed up propagation where it matters the most, but that would require action by the operators of the mining pools. And it could leave out solo miners who don't do that. 18:34:40 IIRC supportxmr runs P2Pool instances on their servers 18:35:24 It's in the interest of mining pools to receive P2Pool blocks faster, and they can just run a node - they don't have to diverge hashrate to it 18:35:54 solo miners can do the same, if they're informed about it 18:37:30 I recently made an issue for making it so normal nodes can fast relay blocks like p2pool: https://github.com/seraphis-migration/monero/issues/454 18:37:47 @rucknium: Relevant: @boog900:monero.social's idea to relay blocks that pass PoW before doing validation would help, so nodes can at least start doing the work in parallel (but yes would still need to request and verify said txs) https://github.com/seraphis-migration/monero/issues/454 18:37:58 Yes, P2Pool implementation must be rock solid in terms of verifying that a specific PoW solution does bind to a specific transaction - but all the machinery is already in P2Pool (merge mining) and it's battle tested 18:38:05 ha, jinx 18:41:22 Monero relaying PoW-checked blocks will not be faster than P2Pool unless it also enables RandomX dataset (+2 GB on RAM requirements) by default 18:41:33 P2Pool does it, Monero daemon is more restricted 18:41:57 i think i have the right idea… 18:42:05 It can be enabled with an environment variable, by it's off by default 18:42:12 *but 18:42:24 It should still make the network as a whole faster rather than just p2pool doing it 18:42:30 true 18:43:00 And it removes the requirement of running p2pool to get fast blocks, for example stressnet has no p2pool at all 18:43:04 P2Pool does bring the block relay to only 1-2 hops on the scale of the whole network, already, so the improvement will be marginal 18:43:58 Because each Monero node is either connected to P2Pool, or 1-2 hops away from a P2Pool-connected node 18:44:34 and P2Pool relays all Monero blocks, not just its own 18:44:57 but we digress from the 0-fee PoW transactions topic 18:45:21 Its an easy change to allow blocks to be invalid if the pow is valid 18:45:43 I don't argue that, I'm just saying the improvement will be marginal (but there will be an improvement) 18:48:35 More discussion on this? I will keep it on the agenda next time. 18:49:38 1-2 hops could be >5-10s if the block has 128-in txs fwiw 18:49:58 also true, especially for FCMP++ 18:50:53 then it's not so marginal improvement, I'm for https://github.com/seraphis-migration/monero/issues/454 18:51:31 I would rather specific miner consolidation txs rather than 0 fee txs 18:52:05 Same, but there were strong arguments against a specialized tx type 18:52:34 so it was decided not to introduce them in the next hardfork 18:52:37 I think (?) 18:53:02 My preference is: (1) miner consolidation tx type (2) PoW-admitted 0-fee tx 18:53:23 and (3) regular consolidation tx paying regular fee - the worst for P2Pool adoption 18:53:39